Using Git Flow and SourceTree

This is a Servoy Tutorial on how to use Git, Git Flow, and Atlassian SourceTree (GUI for Git Flow) with Servoy. In this Servoy tutorial I present the Git Flow model that is working well for me on all my big projects. I also explain how to setup Git Flow with Servoy, and even include a video demonstrating how to do some basic branching.  It should be enough to get you started.

Using a repository for source code control is imperative, regardless if you are a lone developer, a small team of developers, or a big team. Without it, you are in big trouble; its only a matter of time before you loose it all due to a hard drive failure or other disaster.

I’m not going to get into a debate with anyone over the pros and cons of Git versus centralized source code control systems like subversion or svn. There are plenty of flame wars on this topic already underway on the web. The bottom-line for me, is that Git is designed for branching, where as for other centralized systems like svn, it is an advanced topic and considered a bit scary (“watch out for merge conflicts…”). With Git, branching is extremely easy and part of my everyday workflow. I can create feature branches, hot fix branches, release branches, collapse branches, all without fear, and with minimal effort. I will never go back to a centralized system like svn, and any client I work with, will be lectured on the importance of switching to Git. Yes…I feel that strongly about it.

With Git there is a central repository (repo) called origin. Each developer then has a local copy of origin that they use to make their changes in. When they finish making changes, they can push those changes up to origin. Other developers can then pull those changes down to their local repository. Developers can also push and pull to/from each other, if they want to test something before pushing to origin.

At the core, the Git Flow model has two main branches at origin:

• master (called production in image)
• develop (called development in image)

The origin/master is the branch that is our production ready state. It is the code we have stabilized and is being deployed for our customers.

The origin/develop branch contains everyone’s latest development changes that have been pushed up from their local repositories. This is also where nightly builds are made.

There are several supporting branches that are used in Git Flow in addition to the master and development branches. They include:

• Release branches
• Hot fix branches
• Feature branches

Technically, these additional branches all function the same way. The only real important factor is where they are originate from, and where they merge when closed, which is all handled by Git Flow (think of Git Flow as the Git workflow).

When the code in the development branch reaches a stable point, a release branch can be made using the Git Flow button in SourceTree. This will create a new release branch from development, isolating the code into a new release branch, where it will be stabilized until it is ready to be released into production. A build is prepared from the release branch and installed on QA servers, so that testing can begin. If any fixes are needed, developers can easily switch from their development branch to the release branch, fix the issue, make a new pre-release build, and deploy it for QA. This is really where the Git repo system begins to shine.

The QA testing and fixing on the pre-release branch continues until a point where it is now ready to go to production. At that point, Git Flow is used to close the release branch and merge it into the production and development branches, ensuring that all changes made in the release branch, are merged back into both. Once merged into production, a build is prepared for distribution to all production servers.

At any point in time, if a critical issue is detected in production, a hot fix branch can be made using Git Flow. Developers can easily switch to the hot fix branch, resolve the issue, and then merge it back into production and development.

Feature branches are made off of development, and allow developers to work on significant and large features, thereby isolating that work. The release timeline for the feature may well be unknown, and if an experiment that ends in disaster, does not affect any other work in the development branch, and can simply be discarded. After a feature has been fully developed, it can be collapsed back into the main development branch.

There is no limit to the number of feature branches that can be open at one time. This lends itself really well to an agile development environment, where developers constantly have to switch branches to work on new features as specifications are gathered that are required for work to proceed.

By isolating these features off of the main development branch, the team is still able to cut a release at any time, and not worry about the effects an unfinished feature may have on a new release.

There is really nothing unique about this branching model outlined here; it is simply the Git Flow built into SourceTree, and it works really well with Servoy and the needs of today’s agile development teams. More importantly, with Git Flow, the branching strategy forms an elegant model that is easy to comprehend and allows all the team members to move forward with confidence in a unified branching and release process.

Git Flow is where its at, and SourceTree is the tool to use. Let’s set it up and get to work!

Here are the Servoy tutorial steps to setup Git and SourceTree with Servoy.

• Download and install Git.
• Download and install SourceTree.
• Install EGit in Servoy Developer (Eclipse). Install Mylyn at the same time (you should be using this for tracking code context on tasks regardless if you are using Git or not; see TaskTop for more info).
  
• Prepare a new workspace folder for your Servoy project.
• Go to bitbucket.org and get yourself a free repository.
• Open SourceTree.
• Click Clone/New and add your repository using the “Clone Repository” tab. Point the directory at your new Servoy workspace, which should be empty right now.
  
• Add a simple text file to the Servoy workspace. You will see an “Uncommitted Change” in SourceTree
• Click the “Commit” button, and you will get a dialog that looks like this:
  
• Click the arrow to stage the changes.
• Click Push commits immediately to “origin”.
• Enter a commit message describing what you are committing (everyone will see this). Your finished commit dialog should look like this:
  
• After your first commit, you should have a branch called “master”, and you should have been switched to it automatically. My view shows two commits, but you get the idea.
  
• Next, click on “Git Flow” and verify that your branch names are acceptable. For example, you could call the “develop” branch “dev” if you wanted to.
  
• Click “Ok” to initialize Git Flow. Git Flow will be initialized and you will be switched to the “develop” branch.
  
• Next, setup your SourceTree to use your local installed Git, and setup a .gitignore_global exclusion file. This global exclusion file should be in the root of your new workspace folder; it will prevent certain files from being included by Git.
  
• Here is what my exclusion file looks like:
  
• Next, put your entire Servoy project (including the .metadata folder) into your new Servoy workspace.
  
• In SourceTree, click on “Commit”. The commit dialog will appear and you will have lots of working copy changes.
• Click the double arrow to “Stage All” changes.
• Write a commit message.
• Check the “Push commits immediately to origin” checkbox. This will push your local commit up to the repo on bitbucket.
  
• Click “Commit”.
• When the commit is done, SourceTree should look something like this:
  
• Now launch Servoy and open the new workspace you just created for Git.
• Add the Git perspective to your views.
  
• Click “Add an existing repository”, and browse to the new workspace you setup for Git.
  
• Your perspective should now look like this:
  
• Make sure the Navigator view is added to your main Servoy perspective. When you switch branches in SourceTree, you will need to use this view to highlight all your modules, right-mouse click and refresh. This ensures that your searches, for example, do not thrown any errors because files are out of sync. Also, when you have multiple branches available, Servoy will show you what branch you are currently on.
  
• The next step is to share all your projects with the team. Highlight everything you see in the navigator, right-mouse click, select “Team: Share Project”.
• Select Git as the repo to share with.
  
• Setup your Share Project dialog something like this:
  
• Your navigator view should now look like this:
  
• When you switch to a new branch in SourceTree, your navigator will show the new branch you are on. Basically, the files in the workspace that Servoy is working with, are swapped out with new copies from the branch you switched to.
  
• You are done setting up Servoy/Eclipse, Git, Git Flow, and SourceTree. Begin development.

This video will demonstrate how to work with GitFlow in SourceTree, and do basic branch switching. I think watching it in use, as opposed to a written description, makes more sense for this Servoy tutorial.

Well, there you have it; how to setup Servoy/Eclipse, Git, Git Flow and SourceTree. As I said at the start, Git Flow is so much easier to work with then svn or subversion (in my opinion), and it does a much better job in allowing you to switch branches, something that is a frequent occurrence throughout the day in our fast paced agile environments. Give it a try now; once you do, I know you will convinced, and never go back.

That concludes this Servoy tutorial. I hope you found it helpful.