Bootcamp
Search…
0.5.2: Git Branches

Introduction

Git repos can consist of several parallel series of commits called branches. This is helpful when there are multiple engineers working on the same repo and each is working on their own feature, which may require 1 or more independent commits. Engineers develop features on their own "feature branches" so that they do not interfere with development of other engineers.
So far in Basics and Bootcamp we have only worked on the main branch, but in teams we almost never want to code on main, because main is reserved for tested and approved code running in production. Once a developer completes their new feature in their feature branch, they can merge their branch back to main to "release" the feature to their teammates and users.
Developers typically work on feature branches before merging changes back to main.

Why Use Branches

Team Work

Dev teams use branches to work on a project simultaneously without affecting each other. Engineers on teams create a new branch for each new feature, which can be as small as a typo bug fix, or as big as a new product. Once a branch has been merged to main, it can be deleted.

Solo Work

Some engineers use branches even when coding solo for a few reasons.
  1. 1.
    To keep track of different sets of changes simultaneously.
  2. 2.
    To try things out without copying files, e.g. keeping a "safe" version in main.
  3. 3.
    To designate code for different features of a project.

Using Branches

Create a Branch

Create a new branch named "my-feature". git checkout allows us to switch or "checkout" branches, and the -b flag creates a new branch and checks it out.
1
git checkout -b my-feature
Copied!
Verify we are on the new my-feature branch with git branch.
1
git branch
Copied!
Once on a branch we can make commits that build on the state of main when we created the branch. New commits on our branch will be independent from new commits on any other branch.

Change Branch

We should commit changes before switching branches to avoid polluting other branches. Run git checkout without the -b flag to checkout an existing branch.
1
git checkout main
Copied!

Branch Naming

We name branches with kebab-case by convention if there is more than one word.

Git Merge

Basic Usage

Git Merge attempts to merge commits from 1 branch to another.
When we are done with our feature, we may wish to merge our work back to main so others can admire our work. Here is how we can do this.
  1. 1.
    Checkout the branch we want to merge into. E.g. if we want to merge our changes to main, we should checkout main.
  2. 2.
    Run git merge followed by the source branch, e.g. my-feature.
    1
    git merge my-feature
    Copied!
  3. 3.
    Git will combine commits from both branches and create a "merge commit" to resolve any differences.

Advanced Usage

We do not only merge feature branches to main. Often when developing a larger feature, we will want to merge main into our feature branch periodically to verify whether our changes still work with the latest code on main. This is to pre-empt situations where someone may have committed changes to main that are incompatible with the features on our branch.
We can also use Git Merge to merge changes from main to our feature branch.

Merge Conflicts

What are Merge Conflicts

Git is not always able to resolve differences between 2 branches automatically. If two branches change the same lines of the same files, there may be a "merge conflict". Merge conflicts are typically a result of miscommunication between team members, where both team members edit the same code in different ways at the same time.
Merge conflicts look like this.

How to Resolve Merge Conflicts

  1. 1.
    Once we have a merge conflict, we must resolve the conflict before doing anything else with Git. Merge conflicts can be intimidating but can be easy to resolve.
  2. 2.
    Run git status to see which files have conflicts.
  1. 1.
    Open the files in red from git status output. These have merge conflicts.
  2. 2.
    Git will have added the following lines to our code to indicate where the conflicts are.
    1. 1.
      HEAD represents the latest commit in your repo. The changes from HEAD start at the following line.
      1
      <<<<<<< HEAD
      Copied!
    2. 2.
      The changes from HEAD end at the following series of equal signs, and the changes from the conflicting branch begin after the equal signs.
      1
      =======
      Copied!
    3. 3.
      The set of conflicting changes from the spelling branch ends with the following.
      1
      >>>>>>> spelling
      Copied!
    4. 4.
      If you're not sure where to find the merge conflict, search for the repeated <, =, or > characters above. VSCode highlights merge conflicts in our files, providing convenient buttons to choose 1 change or another.
  3. 3.
    Once we've found each merge conflict, decide which changes to keep. Edit the file to the way it should be after this merge, removing all Git symbols and irrelevant code.
Example merge conflict containing the above conflict symbols.
  1. 1.
    Once we've fixed merge conflicts in all files, we can add them to staging and commit them. This will trigger Git to create a merge commit with an auto-generated commit message.
  2. 2.
    Though we've "resolved" the merge conflict, Git does not check if our app still works. Remember to remove the Git symbols, or we may get a syntax error!
  3. 3.
    If we are unable to resolve the conflict because we are unsure which changes to keep, we can abort the merge for now with git merge --abort.

Exercises

Branch and Merge Without Conflicts

  1. 1.
    Create a new repo.
    1
    mkdir poems
    2
    cd poems
    3
    git init
    Copied!
  2. 2.
    Create a poem about water in water-poem.txt. Commit this file to the repo.
  3. 3.
    Create and checkout a new branch to edit the water poem.
    1
    git checkout -b water-poem-edits
    Copied!
  4. 4.
    Edit the water poem and commit it to the new branch you just created.
  5. 5.
    List all branches.
    1
    git branch
    Copied!
  6. 6.
    Checkout main.
    1
    git checkout main
    Copied!
  7. 7.
    Verify water-poem.txt has reverted to the version on main.
  8. 8.
    Create a new poem about sandwiches in a new file and commit it.
  9. 9.
    Checkout the water poem branch.
    1
    git checkout water-poem-edits
    Copied!
  10. 10.
    Verify the sandwich poem does not exist in the water poem branch.
  11. 11.
    Checkout main and merge the water poem edits from the water poem branch.
  12. 12.
    Verify water-poem.txt contains the changes from the water poem branch.

Resolve Merge Conflicts

  1. 1.
    Make a new branch for edits to the sandwich poem.
    1
    git checkout -b sandwich-poem-edits
    Copied!
  2. 2.
    While on the sandwich branch, add a line to the poem and change the line that's currently there.
  3. 3.
    Commit the changes on the sandwich branch.
  4. 4.
    To create a merge conflict we will commit new changes to the same lines in the other branch.
  5. 5.
    Checkout main.
  6. 6.
    Make a change to the sandwich poem and commit it.
  7. 7.
    Merge the sandwich branch into main.
  8. 8.
    We should observe a merge conflict.
  9. 9.
    Open the sandwich poem file to see the merge conflict symbols from Git.
  10. 10.
    Resolve the merge conflict as per instructions above.