Source control packages always have been a bit of a pain when you first start using them. You may know the principles of source control. Each environment has its own way and definitions and its own processes. Once you are used to using a source control system and the steps you follow it is easy. I call this the Source Control shuffle.

It’s always good to have a workflow that allows for code review and this process below will provide a method to do this by using branches and merging back into the master.

The branching, committing and merging workflow for projects using git source control.

Guiding Principals

• master is always production ready and suitable for deployment
• create a new branch for every feature or fix
• on each branch, NEVER work on anything but the specific task related to it. If you see other work that needs doing during the course of development, submit a ticket for it, or check out a new branch.
• rebase during feature development, explicit ( --no-ff ) merge when complete.

Feature Process (or the shuffle)

New features that are added to the product for a future release.

N.B. bug fixes that should go into the next feature release, rather than a hotfix, should also use this process.

1. Pull down the latest changes from master.

   git checkout master
   git fetch origin
   git merge master
   

2. Create a new branch for the work. Use the issue key followed by a descriptive name for the branch.

   git checkout -b PRJ-123-feature-name

3. Work on the feature.
   1. Make regular commits
   2. Avoid clustering changes together.
   3. Push to remote as needed, to keep a backup of your work.
   4. If you need to work on another task, ensure all changes are committed before creating a new branch or switch to another one.
   5. Only one developer should work on a feature branch. If more than one developer needs to work on the task, each should branch off again (including the first developer to start work) from the shared branch. Merges should be made to the task branch as per the central workflow.

4. Keep your branch up to date with the latest changes on master

   git fetch origin git rebase origin/master

5. When ready for feedback and/or code review, push to remote and create a pull request.

   1. Push to remote:

      git push -u origin PRJ-123-feature-name

   2. Create a pull request on VSTS to merge the feature branch into master:\
6. Code review should now occur. If changes are required, they can be committed and pushed to the same branch. The pull request will be automatically updated with any new commits.
   N.B. Any changes made from now on should occur using merges only. If master needs to be merged into the branch to update it, you should not use rebase, as this will cause problems with the pull request.
   Once the review is complete, perform a final rebase (see Feature Process above) to prepare to merge. Then push to remote again (see 5.a above).
7. The pull request should now be completed on VSTS. This will create a merge commit. There should be no actual changes or conflicts in this commit if the previous procedures have been followed correctly.
8. Delete the feature branch. This is an option on the remote during the pull request completion in VSTS. The branch will also need to be deleted locally by the developer:

   git branch -d PRJ-123-feature-name

Hotfix Process

Bug fixes that need to be applied to the currently released version (or to patch a previous version that is still supported) and require a new patch version release.

1. Pull down the latest changes from master (see Feature Process 1. above).

2. Check out the tag of the release you want to hotfix, branch from it and check out the new branch:

   git checkout v1.0.0 git branch PRJ-199-hotfix-name git checkout PRJ-199-hotfix-name

3. Work on the bug fix, following the notes in Feature Process 3.
   N.B. It is important that you DO NOT follow step 4. of Feature Process, as changes from master should not be brought into your hotfix branch.
4. When ready for feedback and/or code review, push to remote.
   N.B. DO NOT create a pull request to master.
5. Follow the Release Process, using the hotfix branch instead of a release branch.
   N.B. hotfix/patch releases should contain just one bug fix.

Release Process

This process starts when preparing to make a release after all code tasks for that release are merged into master. Final work may still be necessary to complete the release.

1. Create a new branch from, master either in git directly, or locally, having first pulled the latest changes from master. If you create the branch locally, the currently checked out branch will be used to branch from.
2. The branch should be named release with the version number appended, e.g. release-1.1.0
   This marks the point at which no more features will be added to the release. Only adjustments and bug fixes necessary to put the release into production should be applied to this branch.
   However, work can continue on new features for other releases, by branching off, master as covered above.
3. Any further work to prepare this release should be merged into this release branch, using the same process as Feature Process, but creating pull requests to and rebasing from the release branch, instead of master.

4. Once the release is ready, update the assembly version in the release branch to match Jira and commit, then deploy the build via the deployment machine – this will usually involve checking out the new release branch, running the grunt script to grab the correct web configs and log4net configs and then deploying from Visual Studio.

5. Note that the version number as reported in the health check will always have 4 digits even though we are only using 3.

6. Create a tag on the release branch once you are happy that the release was successful

   git checkout release-1.1.0 git tag v1.1.0 git push --tags origin release-1.1.0

7. Merge the release into master after the release has been tested and is finished: If there are any errors with the release, a decision will need to be made by the Development Manager whether to fix the release branch or to revert the release and do it again.
8. Merging back into master should be done with a pull request on git.
9. The release branch can now be deleted.