Basic fork/pull git workflow


April 6, 2013

Typical simple workflow for a (github) repository with few users.

Permissions configuration:

Main developers have write access to the repository, occasional contributor are supposed to fork and create pull requests.

Main developer: Small bug fix just go directly in master:

git  checkout master
# update from repository, better use rebase in case there are unpushed commits
git pull –rebase
git commit -m “commit message”
git push

More complex feature, better use a branch:

git checkout -b featurebranch
git commit -am “commit message”
# work and make several commits
# backup and share to github
git push origin featurebranch

When ready to merge (cannot push cleanly anymore after any rebasing):

# reorder, squash some similar commits, better commit msg
git rebase -i HEAD~10
# before merging move commits all together to the end of history
git rebase master
git checkout master
git merge featurebranch
git push
# branch is fully merged, no need to keep it
git branch -d featurebranch
git push origin –delete featurebranch

Optional, if the feature requires discussing within the team, better create a pull request.
After cleanup and rebase, instead of merging to master:

# create new branch
git checkout -b readyfeaturebranch
git push origin readyfeaurebranch

Connect to github and create a pull request from the new branch to master (now github has a shortcut for creating a pull request from the last branch pushed).

During the discussion on the pull request, any commit to the readyfeaturebranch is added to the pull request.
When ready either automatically merge on github, or do it manually as previously.

For occasional developers: Just fork the repo on github to their account, work on a branch there, and then create a pull request on the github web interface from the branch to master on the main repository.