Git Workflow Best practices

Question

Stupid question and treat me as completely a newbie to version control.

I'm new to Git (I've used subversion before, but just the basics) I understand the basics of Git and its branching commands, I have an imaginary situation that need your advice.

Suppose my software currently is at v1.2, stable and released.

My Software
       v1.0
       v1.1
       v1.1.1
       v1.2 <- Current, Compilable and Released

Scenario:

I have two developers, John and Eric.

• John is responsible for bug fixes reported by clients.
• Eric is responsible for new features, experiment with them and work out the kinks.

It's January right now.

John is working on lots of bug fixes based on the v1.2 release. Every day he's required to commit his code back to the repository (GitHub), software might not compile depending on his status.

Eric is experimenting this new wiki feature from basic features like add a WYSIWYG editor, to advanced features like diffing/version control, again, he's required to commit his code back to the repository, software might not compile either depending on where he's at.

Goal

1. At any time, I can pull out a stable, compilable v1.2 release
2. February, I want v1.3 to be pushed out with all John's bug fixes and depending on if Eric is done (at least have the basic feature done), release that as well.

With GIT, what is the workflow?

If I understand GIT correctly, both Eric and John should create their own branch and in Feb, have them merge what works with the master?

Thanks

Answer 1

I would set up two integration branches in the main repository:

1. master: integration branch for new features (maintained by Eric)
2. 1.2-stable: integration branch for bug-fixes (maintained by John)

Please note that these branches should only be used for integration purposes, i.e. for merging finished work from other, so-called feature branches. Development and bug-fixing should be done in the feature branches. In this workflow the code in the integration branches always works.

Both developers should have one feature branch for each task they are trying to accomplish. In your case Eric would have a branch called wysiwyg that starts at the tip of the master branch. When the feature is ready to enter the mainline of development Eric can simply merge the wysiwyg branch into master.

The same applies to John. If, for example, John has to fix two issues (say, issue1 and issue2) he should have branches fix-issue1 and fix-issue2. These branches should start from the tip of the 1.2-stable branch. After fixing one of the problems, say issue1, John can merge branch fix-issue1 back into 1.2-stable. If the codes in master and 1.2-stable branches haven't diverged too much then it would probably be a good idea for Eric to occasionally merge branch 1.2-stable into master in order to incorporate the accumulated fixes to the next release of the product.

When it is time to release 1.3 Eric should make sure that the accumulated fixes in 1.2-stable branch and ready feature branches have all been merged into master. Then he can simply tag v1.3 and create a new branch 1.3-stable.

Answer 2

The opposite recommendations for who maintains the master branch from Question Mark and kaitanie—Question Mark recommending John work on master whereas kaitanie recommending Eric work on master—demonstrates Git's workflow flexibility.

As far as Chris Nicola recommending rebasing instead of merging, I would provide the same caution as found in Pro Git by Scott Chacon, which is available to read free online and I highly recommend, "Do not rebase commits that you have pushed to a public repository." Since "every day [John is] required to commit his code back to the repository (GitHub)", I would probably stay away from rebasing except where used locally by John and Eric.

I would recommend that you read the "Branching Workflows" section of Pro Git, which describes long-running branches and topic branches. You should probably also take a look at the "Distributed Workflows" section, which describes Centralized Workflow, an Integration-Manager Workflow, and a Dictator and Lieutenants Workflow.