Git branch workflow

Git branch workflow for ScholarSphere

This document was inspired by the Hydra Git workflow, and by the Git-Flow branching model (when we adopt this model, we may well want to use the git-flow tool to simplify the workflow).

Branches

We have two long-lived branches:

• develop – Main development and integration branch.
• master – Contains production-ready commits. No commits should be made directly to master, and commits should only be merged from develop (via a short-lived release or hotfix branch) by a release manager, according to our release management process.

All other branches are temporary, are not ordinarily pushed, and should be deleted when merged. Such short-lived branches may include:

• feature/topic branches – Feature branches must be branched off of develop and merged back into develop (and only develop). These branches should correspond to ticket numbers in our SCM system (Redmine), e.g., SCM-1417 for ticket #1417. The naming should not matter much, since these branches often are not pushed or worked on by multiple coders, but they may be, so it’s good practice to name them according to this convention.
• numbered release branches – Numbered release branches must be branched off of develop and merged back into both develop AND master. Such branches should be merged back into master FIRST, then tagged with a version number, and THEN merged back into develop. Once these merges have occurred and merge conflicts have been resolved, the numbered release branch may be deleted. These branches should correspond to numbered releases, such as v1.2.1. These branches are created to handle finalization of code that is slated to be released as a particular version; this work is done in a branch to allow other work to continue in develop. Release branches should not receive large new features; those go into develop for inclusion in future releases.
• hotfix branches – Hotfix branches must be branched off of (the appropriate tag in) master and merged back into both master first AND then develop. Hotfix branches always result in a new version number, and should result in only patch-level (not major-level or minor-level) version bumps. NOTE: if the hotfix is for a version that currently has a numbered release branch, then changes should be merged back into that branch and not develop.

Create a feature branch

user@host:~/workspace/scholarsphere (develop)$ git checkout -b SCM-558
user@host:~/workspace/scholarsphere (SCM-558)$ 

This creates a feature branch and switches you to it.

Write some code

Make changes to your code, add them, and commit them like usual. Keep doing this until your code satisfies the ticket, or feature, you’re working on, and all of your tests pass.

Catch up with develop

When you’re done working on your ticket and ready to push your changes, it’s time to rebase. Git’s rebase will pull all code from origin/develop into my branch SCM-558.

user@host:~/workspace/scholarsphere (SCM-558)$ git checkout develop
user@host:~/workspace/scholarsphere (develop)$ git pull
user@host:~/workspace/scholarsphere (develop)$ git checkout SCM-558
user@host:~/workspace/scholarsphere (SCM-558)$ git rebase develop

At this point we have merged the changes in the develop branch into SCM-558, but we have not merged our code from that branch (SCM-558) back into the develop branch.

After the rebase, ensure all of your tests are still passing. If not, write code and commit until they do, and then merge.

Merge the branch

user@host:~/workspace/scholarsphere (SCM-558)$ git checkout develop
user@host:~/workspace/scholarsphere (develop)$ git merge SCM-558

Run tests, and if they pass, push to github

user@host:~/workspace/scholarsphere (develop)$ rspec
user@host:~/workspace/scholarsphere (develop)$ git push origin develop

Delete the feature branch

user@host:~/workspace/scholarsphere (SCM-558)$ git branch -d SCM-558