Use Feature Branches

The biggest challenge when working with multiple people on the same code is that you all may want to make changes to the code at the same time. Git is designed to simplify this process.

Git uses branches to isolate changes from one another. You think of your source code as a tree, with one main trunk. By default, everyone in git is working from the “trunk”, typically named master or main (you can see this when we used git status above).

Git Branches

A branch is a fork in the tree, where we “split off” work and diverge from one of the commits (typically from a point where everything is working as expected)! Once we have our feature implemented and tested, we can merge our changes back into the main branch.

Notice that there is nothing preventing multiple users from doing this. Because we only merge changes back into main, when they’re tested, the trunk should be relatively stable code.

We have a lot of branching commands:

$ git status	// see the current branch
On branch master

$ git branch test // create a branch named test
Created branch test

$ git checkout test  // switch to it
Switched to a new branch 'test'

$ git checkout master //switch back to master
Switched to branch 'master'

$ git branch -d test // delete branch
Deleted branch test (was 09e1947).

When you branch, you inherit changes from your starting branch. Any change that you make on that branch are isolated until you choose to merge them.

Branching strategies

Option 1: Mainline development

This is a strategy where the most up-to-date changes are kept on main.

• Relatively few branches from main; only created as needed.
• Merge and integrate features to main as they are completed.
• Requires diligent testing and care!
• Releases done from main branch.

Option 2: Release and feature branches

More complex strategies will use separate branches for individual work. Merges are done back to an intermediate release branch, where releases are staged and performed. Main is where all release branches are ultimately integrated.

• Multiple branches, at different levels.
• Merge back to release branches as needed.
• Provides the ability to have multiple, independent releases.
• More resilient to changes, at the cost of complexity.

This model also illustrates the idea of short-lived vs. long-lived branches. Feature branches are created as needed, but are relatively short-lived: once the feature is integrated/merged back into the long-lived release branch, the feature branch can be deleted.

Feature branches

We’ll standardize on a simpler model, closer to Option 1, where we create feature branches for individual work and integrate changes back to main.

Use this workflow for adding a feature:

1. Create a feature branch for that feature.
2. Make changes on that branch only. Test everything.
3. Code review it with the team.
4. Switch back to main and git merge from your feature branch to the master branch. If there are no conflicts with other change on the main branch, your changes will be automatically merged by git. If your changes conflict (e.g. multiple people changed the same file) then git may ask you to manually merge them.

$ git checkout -b test // create branch
Switched to a new branch 'test'

$ vim file1.md // make some changes
$ git add file1.md
$ git commit -m "Committing changed to file1.md"

$ git checkout main // switch to main
$ git merge test // merge changes from test
Updating 09e1947..ebb5838
Fast-forward
 file1.md                   | 136 ++++++++++++++++
 1 file changed, 118 insertions(+), 18 deletions(-)

$  git branch -d test // remove branch (optional)
Deleted branch test (was ebb5838).

When you merge, Git examines your copy of each file, and attempts to apply any other changes that may have been committed to main since you created the branch. In many cases, as long as there are no conflicts, Git will merge the changes together. However, if Git is unable to do so, then you will be prompted to manually merge the changes together.

Pull requests (PRs)

One way to avoid merge issues is to review changes before they are merged into main (this also lets you review the code, manually run tests etc). The standard mechanism for this is a Pull Request (PR). A PR is simply a request to another developer (possibly the person responsible for maintaining the main branch) to git pull your feature branch and review it before merging.

We will not force PRs in this course, but you might find them useful within your team.

GitLab also calls these Merge Requests.

Last Word

https://xkcd.com/1597