knowledge-kitchen

Feature Branch Version Control Workflow and Avoiding Merge Hell

Working on code in isolation and incorporating peer review

  1. Overview
  2. Making Changes
  3. Peer Review
  4. Keeping Git History Clean
  5. Conclusions

Overview

Concept

Software projects in this course will follow a “feature branch” version control workflow, where changes are made in isolated branches.

Following this workflow allows team members to work independently while minimizing code code conflicts.

Repositories

The feature branch workflow requires each developer to have access to two repositories:

  1. a centralized remote repository accessible by everyone on the team, such as a GitHub repository
  2. a local clone of the remote repository

Making Changes

Pull from central repository

Before making any changes, download the latest code from the shared central repository.

With the main/master branch on the local machine checked out:

git pull

Or, if you need to be specific about where to pull from:

git pull origin main

Create a new local branch

With the latest code downloaded, create a new branch and “check it out”. The name of the branch should refer to the user story, task, or spike associated with the changes that will be made.

Example for a Task with identification number 9 belonging to a User Story with identification number 13:

git checkout -b user-story/13/task/9/implement-user-login

Example for Spike with identification number 6:

git checkout -b spike/6/install-mongo-db-locally

Update task board

In the GitHub Task Board for this Sprint, move the card for this Task or Spike to the appropriate “In Process” column.

Make changes locally

Pop open your favorite code editor and go crazy.

Commit changes to the local branch

Add all changed files to the branch in the local repository.

git add .
git commit -m "Implementing user login task from user story #13"

Merge with latest code from central repository trunk

Download the latest code from the main branch of the shared central repository, merge it into the local feature branch, and resolve any conflicts

With the feature branch checked out:

git fetch origin
git merge origin/main

Push branch to remote repository

Once the feature branch has been merged with any recent changes to the main branch, it’s time to upload the feature branch to the shared remote repository.

For example, push a feature branch for a particular Task:

git push origin user-story/13/task/9/user-login

Issue pull request

Once the feature branch has been pushed to the remote repository, the developer must issue a Pull Request to their teammates requesting that they accept the changes into the main branch.

This Pull Request must be made using GitHub, and assigned to the teammates. This forces teammates to perform peer code review on the work before it is included in the main branch.

Update task board

In the GitHub Task Board for this Sprint, move the card for this Task or Spike to the appropriate “Awaiting Review” column.

Peer Review

Review a pull request

A second developer must review the changes in the pull request and either accept or reject them.

Download the feature branch for review

git checkout user-story/13/task/9/user-login
git pull

Look at the code, test it, Try it, etc…. make sure it works!

Merge changes locally

If approved, the reviewer and the original developer coordinate so that one of them merges the changes in the feature branch into the main branch.

Example of getting latest code and merging into main:

git checkout user-story/13/task/9/user-login
git pull
git checkout main
git pull
git merge user-story/13/task/9/user-login

Upload changes to remote repository

Once the changes have been merged into the local main branch, the developer who merged must upload the changes to the remote repository.

With the main branch checked out:

git push origin main

Update task board

Whoever merged the code must now move the corresponding Task into the “Done” column of the task board.

Keeping Git History Clean

Keep it simple… no rebasing

When merging a feature branch into the main/master branch, Git will create a “merge commit” that records the fact that the feature branch was merged into the main branch. This is an important part of the history and must be preserved.

GitHub merge options

Conclusions

Thank you. Bye.