Notes about what source control systems we use and how we use them.
Git
- 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.
Git-SVN
- If necessary, we can convert a SVN repository to git and push it to github, but let's avoid it if possible.
SVN
- 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
| Code Block | ||||
|---|---|---|---|---|
| ||||
git checkout -r 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.
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 R1 it might look something like this.
The release manager will be responsible for merging the pull request into the current release branch (in this case release/1.0.0).