Git is a powerful Distributed Version Control System (DVCS). While ad hoc methods will suffice for single person projects, group projects must follow conventions to avoid undoing the work of collaborators and to avoid redoing stuff that has already been done. This blog is based on Atlassian‘s description of four Git collaboration patterns.
- Centralized Workflow model is suited for small (two or three person) projects which uses Git as just a remote store.
- In the Feature Branch Workflow model the developer is assumed to produce unsafe code and hence merging with the master branch can be done only after due code review.
- The third pattern invented by Vincent Driessen is the Gitflow Workflow. It is somewhat like the Mainline Model (Wingerd 2005) as applied to a distributed version control.
- The Forking Workflow model is suited for third parties contributing to an existing open source project by generating a pull request.
Let us assume that we have a local Git project that is in synch with the remote version. We then make changes to the local version. Meanwhile other colloborators may be makeing other changes as well. When we decide to upload our changes we have to first merge the remote version with our local one before uploading ours to the remote site. The Git commands to do that are listed below:
$ git pull -rebase origin master
This might generate a conflict. Fix the conflict
$git rebase --continue
Fix additional conflict if any and repeat the two steps above until there are no conflicts. If at anytime you wish to abort the whole process:
$git rebase --abort
Once the project has been merged test it again and push it to the remote site
$git push origin master
Feature Branch Workflow
Consider a team with one person who has resposibility for the integrity of the code base. We’ll refer to the person as master. When a developer wishes to add a new feature he/she creates a new branch on the code base and when the feature is ready to integrates he/she informs the master who merges new feature with his local codebase and approves of the new features and then pushes it back to the central codebase for all to use.
The steps executed by the developer are:
$git remote add origin
$git pull -rebase origin master
$git checkout -b feature master
$git push origin feature
The repo administrators then do a merge on their local machine and then push the master back to the repo..
In this model, there are two main trunks, the master trunk and the development trunk. A trunk is essentially a branch except that unlike other branches in this model it is long lived. Other branches can be deleted after their purpose in life has been served. The development trunk has many feature branches. It also has a release branch that contains the next version of the software. There are no new features only bug fixes in the release branch. The master trunk has many hotfix branches that contain only bug fixes to the master trunk. This trunk must ultimately merge with the release branch which must then merge with the development trunk. The following figure from Vincent Driessen (A successful Git branching model) explains it well.
Consider an open source project on Github. If a third party wants to contribute to it,
- they would fork the project on their own repository.
- Then on their local machine create a feature branch.
- Once the implementation is completed
- they would upload the branch to their own repository and
- then generate a pull request from the open source repository from which they forked
The administrators of the open source project may at their discretion merge the pull request with the master. Now the third party can update their main branch. This ensures that the main branch is clean and the third party can now avail of other contributions made to the open source project.
- Laura Wingerd (November 2005) Practical Perforce, O’Reilly Media, Inc.