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 G

Answer 1

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.

Answer 2

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

Answer 3

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 4

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.

Answer 5

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.