Notes about what source control systems we use and how we use them.
- Strictly branch on each JIRA ticket and merge back to master when completed
- Create version release branches when preparing for a release (major or minor not bugfix), when done tag and merge any missing changes to master
- For bugfix releases, make changes in necessary branch and then tag and merge any missing and applicable changes to master
- This is similar to A Successful Git Branching Modelbut with some differences. We might be able to use git-flow if we want to.
- Another approach which doesn't work for us exactly: Github's Git workflow
Do we have a naming convention for the branches? There was some discussion about using the ticket name but I can't remember if there ever any resolution.
- If necessary, we can convert a SVN repository to git and push it to github, but let's avoid it if possible.
- Do we need to use Subversion for anything? Let's try to avoid it.
I personally don't see the need for Subversion unless there is some legacy project we wind up committing to that is still on SVN. For everything we create git is fine.Development work should not be done directly on a master or release branch.
This will allow more fine grained control of what bugs make it into a particular release. Instead each bug should be fixed within its own branch. Name the branch after the open JIRA ticket so there is a relationship between the two.
Creating a bug fix branch
git checkout -b bugfix/vov-xxxx
Completed bugs should include fixes as well as good test coverage that documents the problem. This will prevent the same thing from coming up again after code rewrites / feature changes. Once you are done push your commits to your branch.
git push origin bugfix/vov-xxxx
Merging bug fixes
Once a bug fix is ready to be tested by team members it needs to be merged into the current release. This should be done by issuing a pull request from the same repository. For help on how to do so check Github's documentation.
The release manager will be responsible for merging the pull request into the current release branch (in this case release/1.0.0).
Institutional specific forks
In addition to the generic avalon repository there are localized forks for both Northwestern and Indiana University specific updates. In case the patches apply only to one of these follow the instructions above but replace references to avalonmediasystem/avalon with the appropriate repository. Both should be synced nightly with the main branch to capture any upstream changes. To manage this on your local machine follow these instructions provided by EvanPro.
git remote add upstream git://github.com/avalonmediasystem/avalon.git
This will add a upstream repository that can be referenced whenever you want to merge changes into the local branch.
git fetch upstream git rebase upstream/release/1.0.0 git push origin release/1.0.0