Difference between revisions of "Git workflow"

From SleuthKitWiki
Jump to: navigation, search
(Initial version)
 
Line 1: Line 1:
We are using a variation of the [http://nvie.com/posts/a-successful-git-branching-model/ gitflow] git branching model for The Sleuth Kit and Autopsy.  The differences to it are listed in the section below. This page contains a concise list of steps to do for various things.
+
We are using a variation of the [http://nvie.com/posts/a-successful-git-branching-model/ gitflow] git branching model for The Sleuth Kit and Autopsy.  The differences to it are listed in the section below. This page contains a concise list of steps to do for various things. Much of it is identical to the more explanatory gitflow page.  
  
 
= Cheat Sheet =  
 
= Cheat Sheet =  
 +
 +
== Adding a Feature ==
 +
1. Make a feature branch:
 +
<pre>
 +
$ git checkout -b myfeature develop
 +
</pre>
 +
2. Make the code changes to it.
 +
3. Upload to your repo.
 +
4. Make a pull request.
  
  

Revision as of 12:49, 11 August 2014

We are using a variation of the gitflow git branching model for The Sleuth Kit and Autopsy. The differences to it are listed in the section below. This page contains a concise list of steps to do for various things. Much of it is identical to the more explanatory gitflow page.

Cheat Sheet

Adding a Feature

1. Make a feature branch:

$ git checkout -b myfeature develop

2. Make the code changes to it. 3. Upload to your repo. 4. Make a pull request.


Making A Release Branch

Created before we do the final release.

$ git checkout -b release-1.2 develop
[EDIT VERSION NUMBER]
$ git commit -a -m "Updated version number"
$ git push origin release-1.2

Making Changes to Release Branch

Make commits to the release branch AND merge them into develop. It is the responsibility of the developer at the time of the commits to merge them into develop. This makes it easier than reconciling conflicts afterwards.

Finishing the Release Branch

Merges release branch to master

$ git checkout master
$ git merge --no-ff release-1.2
$ git tag -a 1.2


Differences from gitflow

- We will have multiple develop branches if we are working on backward incompatible API changes on two major versions. I.e. develop could be on the 3.1 version of Autopsy and we could have develop-3.2 with changes that are for 3.2 while we are also working on some minor changes to 3.1. - The developer needs to push to relevant branches at the same time (release and develop or develop and develop-3.2) and not rely on merging later. The developer has the most context about how to resolve the conflicts.