Git Workflow Best practices

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.
开发者_如何学C

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

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.

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.

GIT is very flexible and you can tailor your usage to your specific scenario. That said, I like the branch-per-feature approach and I also prefer "rebasing" to merging.

Branch-per-feature means you create a branch for each feature or defect you are working on. Typically the branch only lives as long as the development and is deleting once it is merged/rebased with the master.

Rebase means that instead of having the branch merge with the master you actually pull the changes from master down and puts them in front of all the changes you made in your branch. In essence it merges the HEAD with the beginning of your branch changes. This makes it seems as if all the changes you are merging began after the the latest HEAD revision.

It is also good practice to push your branches to the remote repository, in case someone else needs to look at or work with the branch, also it provides a backup of your work. Again when you are done with a branch I suggest cleaning up after and deleting old branches.

Finally, one last best practice is to keep your commits small, specific to one particular task or action so that each commit can be examined easily by others and what was done quickly understood. Commits can then serve to document your progress and activities.

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?

yes

John should work on master, Eric should work on a branch named WYSIWYG or some branch named appropriately.

If you want to checkout what could be version 1.3 you should push John's master branch to a new branch called stable if you don't have it already, if you do have a stable branch already, simply merge master into stable again, this would be done each time you want to release some bug fixes.

If Eric is finished on the wysiwyg branch, merge that in as well and then you have your compilable release. you then archive/destroy/ignore the wysiwyg branch as it is no longer needed.