Do you know when to branch in git?

The best way to handle continuous development and deployment is following GitHub Flow. The basic idea is to always deploy from main , and to create a feature branch for every feature. When the feature is complete, it is merged back to main via a pull request, which provides a trigger for other developers to build.

Using this strategy, main is always production-ready and deployable.

finishing a feature with world class flow — Finishing a Feature with World Class Flow

Note: This rule applies to git. For branching advice in TFVC, see when to branch.

commit master bad — Figure: Bad example - Committing to main

commit branch good — Figure: Good example - Committing to a new branch

github flow — Figure: Great diagram from GitHub

The process

Assumption

Set up build system to deploy from the main branch

Your build systems should always deploy from main, and should automatically deploy on every commit to main.
Since main is always being deployed, it must always be in a deployable state.

Step 1 - Create a branch

a) Create a "feature branch" for every PBI

When starting a PBI from the task board, create a branch from main with a descriptive name for that feature.

git branch start-stuff

Figure: Bad example - Branch name is not descriptive

git branch feature/1234-create-basic-web-application

Figure: Good example - Branch name describes the intent of the change and follows a branch naming convention

It is critical that this branch always comes off main, not another feature branch. Main is the only branch that is mandated to be in a deployable state, so any other option is unsafe.

Obviously, we're creating a lot of branches and merging a lot under this strategy - and that's ok. Be sure to keep your PBIs small (as per breaking large tasks into smaller tasks), and you will not have much merge pain.

The benefit of creating feature branches is to reduce the number of conflicts and churn of unfinished code during development of a feature. It allows features to be developed independently of each other and reduces the amount of expensive "pull latest from the server, and rebuild everything" operations, as well as greatly limiting the impact of commits with unfinished code.

b) Code away and complete the PBI

c) Create a commit - it will contain your changed files on your local PC

While working, commit frequently to this branch with nice, descriptive messages. For example: "Added a field to hold the product category to our timesheet read model" or "added a column to the timesheet summary UI for the product category".

git commit -m "Started report change"

Figure: Bad example - Commit message does not describe what was changed

git commit -m "Added a product category filter to the timesheet summary report UI"

Figure: Good example - Commit message describes exactly what was changed

d) Push your changes to your remote Feature Branch

Step 2 - Open a pull request (to merge from your current branch to the main)

When the change is complete, or when you want feedback on anything, open a pull request to merge the branch back to main. The pull request is more than just a request to merge, it is a request to have someone review the code and architecture, or image and to discuss any issues. Resolve these issues with more commits in the branch before continuing.

Tip: A best practice is to have another developer review your work and then approve.

It is easy to chalk this step up as busy-work, but it is one of the most valuable parts of the strategy.

Assumption

Deploy the changes to a staging environment. This allows the features to be tested before being merged to main.

Some prefer to move this step to after the merge, especially when using a release management tool like VSTS Release or Octopus Deploy (see Do you use the best deployment tool). If you decide to go this route, remember that main should remain deployable and production ready at all times and that all branches come from main. If skipping this step, ensure that you have CI on your feature branch to ensure that your branch compiles and passes all tests before merging.

Step 3 - Merge and Deploy (to main)

Once everyone is happy and everything is tested, complete the pull request, which will merge back to main. Ensure you are not using the "Fast Forward" merge option (git), or details about the branch will be lost - it will appear as though all work was done in main. Being able to see the feature branches in the git log is very useful.

GoodGitHistory — Figure: Good example - Each change is well described, small and in its own feature branch

After you completed the pull request, make sure you also delete the branch that you made the pull request of. Deleting your completed branch will not just help yourself in the long run, but also everyone else. Having too many branches especially a stale one will confuse developers on what "may" be in progress, moreover it would cause so much pain to the future developer when they have to do a clean-up and the branch author has left.