Git Workflow in GForge

While GForge has support for CVS and SVN, most of our customers have moved on to Git.  What gets buried in that integration is our customers have a choice on how to use Git and they can have GForge enforce some basic rules.  Today we are going to address implementing a common Git workflow in GForge.

For small projects with one or two developers you may not require workflow and in these instances you can happily clone, commit and push changes right to your master branch.  GForge has been engineered to accommodate even the smallest of projects so we support this model just fine.  Organizations with larger projects don’t want developers pushing code to their master branch because it typically represents the current, stable build.  Instead they opt for a review process of new code that is then systematically reviewed and tested before being pushed to master.  GForge’s Git integration supports this and to show how it works we’ll be using a real-world example.

Internally our work uses the same workflow for new development work and bug fixes:

1. Task is created
2. Task is prioritized and eventually assigned to a developer by a project lead.
3. Developer does their work
4. Developer requests a code review
5. Code review is performed and, if successful, is published for testing
6. QA confirms the code is working through a series of tests.

To support this, our tasks have the following workflow through statuses:

1. Awaiting Assignment
2. Accepted
3. Ready for Merge (Code review)
4. Fixed: Test for Release
5. Fixed: Closed

The steps above represent the happy path for all tasks.  We have additional workflow rules to cover the not-so-happy path for things like failed code review or failed test results.  To make this work in Git we have the follow rules:

1. Our master branch in Git is always our last stable release.  So while we are currently working on GForge v6.4.2 the master branch currently holds a snapshot of v6.4.1.
2. We have an integration branch called gforge-next.  This holds all of the work that has gone through the above steps for v6.4.2
3. Each task assigned out get it’s own work branch, i.e. #1234-bugfix-of-some-sort.  These work branches hold only the code required to satisfy the work described in a single, atomic, task.

So naturally there needs to be a way for a workbench to get into gforge-next and then eventually into our master branch.  To handle this our internal tracker has a custom field we’ve created called “work branch”.  When a developer starts work on a new task they will create a new work branch from gforge-next and give it a name i.e. #1234-bugfix-of-some-sort. When they commit their work to that work branch they will push it and then move task #1234 into “Needs Merge” status.  Another developer will checkout the work branch and perform the code review.  Assuming the code review is accepted, then the developer who did the code review will merge the work branch into gforge-next.  For all the other tasks in a given milestone this same process would happen.   Here’s a screenshot of a ticket awaiting a code review:

As that is happening we deploy the gforge-next branch to a server where we do our testing.  This means that as tasks hit the “Fixed: Text for Release” status, QA will grab the task and test the task works as expected.  Once the tests pass then the task is marked “Fixed: Closed”.

Finally as we close out a milestone, say completing v6.4.2, once all the tasks have been marked “Fixed: Closed” we will then prepare a new GForge release by merging gforge-next into master and then tagging that state of master with the version number being released.  Incidentally, once we have updated master we will then go in and remove all the work branches and then begin work on the next major milestone.

As you can see, we place no restrictions in how you use Git and you can implement any Git workflow you want.  If you have questions regarding this feel free to post a comment below or customers can send questions to support@gforge.com.