A pragmatic Git strategy for fast moving teams

Git is a wonderful tool that is so flexible you can use it in many ways.  With that has come the discussion of how to use it best.  Of course, the answer to depends on your priorities.

Here are the priorities I see often in agile teams delivering software fast:

1. Members of the team need to work in temporary isolation (read: branches)
2. Git and git history is a way to communicate your code changes to the rest of your team
3. You have tests that give you confidence in your final code
4. Recent Git history is valuable if something goes wrong
5. When you build something, you ship it asap

Let's apply these principles to our thinking about various parts of a Git strategy:

Feature branches:  A pair (or a soloing dev) should work on a branch (isolation), and branches are best organized by topic.  Feature work should be short lived so it does not diverge.  Merge master back into the feature if in doubt.  

git checkout feature

git merge master

Feature branches can all start with a common prefix (ft_) but they do not have to.   

Release branches:  If we really ship all we have, every time, there should usually be no need for release branches.  Just release master, optionally from a couple of commits ago.   If you are just in the middle of a big change, either do not merge that feature yet or make a once-in-a-lifetime release branch. Tag your release:

git tag release-1.1 

git push origin release-1.1

Merging features:  A feature branch will have detailed commit history on it, which is great if you need to go back to it next week.  But to keep master easy to follow, you squash your work into one commit when it goes to master.  Keep the feature branch around for 4 weeks, then delete it.

You can accomplish this in many ways, this one is easy to understand:

git checkout feature # Use the name of your branch here

git checkout -b temp  

# Solve any conflicts between feature and master:

git rebase master 
## if conflicts occur, fix, git add and git rebase --continue

git checkout master
git pull

git merge --squash temp

git commit 

git branch -D temp

At this point, you feature branch will not have changed and all the work of merging it with master is hidden in one commit on master.  Write a recurring calendar event to delete old branches on the first of each month.

During the 'git rebase master' step, you may have to merge files multiple times.  This is tedious but it makes the individual merges easier.  If you are impatient, skip this step and deal with the conflicts during the merge step. 

If your feature branch warrants two or more commits: It happens, you did two things in one feature.  Proceed as follows:

git checkout feature

git checkout -b temp  

# Solve any conflicts between feature and master:

git rebase master 

# Reduce to a few commits:

git rebase -i master 

## An editor will open up, change the 'pick' to 'squash' on all 

## lines except the first one and other final commit.  

# Now update the commit message if you haven't already done that:

git commit --amend  

# Merge and clean up

git checkout master

git merge temp

git branch -D temp

Happy working with Git!