Git Branching Model - acechase/software-engineering GitHub Wiki
- This is meant to be as lightweight as possible, just enough process as is useful.
- As a general rule, commits should go onto short-lived, descriptively named branches.
- On completion, feature and bugfix branches should create pull-requests via github.
- Appropriate feedback on a branch can be collected as warranted and then the pull request is merged in (by either reviewer or author)
- Hopefully the master branch is ready to have a release branched off it at any time.
- As you become comfortable with it it takes very little time and really helps members of the team clearly understand what others are working on.
Standard flow
$> git checkout master
$> git pull origin
# always nice to start from the most up to date version of master
$> git checkout -b features/some-sweet-new-feature master
# do some work, some commits. send it up to github
$> git push origin
That's it. Once you've pushed to origin then the pull request and merge can be done through github. You'll sometimes need to do more, like rebase the master before the merge so that the merge goes cleanly.