Exercise notebook: Git branching

Offered by: Digital Work at Otto-Friedrich-Universität Bamberg License: CC BY 4.0

Edit The notebook builds on our peer-reviewed pedagogical foundations. The interactive visualization and tutorial are based on the amazing learnGitBranching repository.

We Edit your feedback and suggestions on this notebook!


Concepts: Git branching

The slides explaining Git branching are here.


With this notebook, you can practice branching in Git.

Practice Label Time (min)
1 Commit, branch, merge, rebase 23
2 Branching strategies 5
3 Merge methods 40
4 Wrap-up 2
  Overall 70

Edit We are here to help if errors or questions come up!



Part 1: Commit, branch, merge, rebase

We have covered git commit, as well as git branch, git switch, and git merge operations in the lecture.

Task: To practice branching and manipulating the Git graph, complete level 1 (introduction) of the learngitbranching tutorial.

Hints:

  • You can always type undo to undo the last command
  • You can run git commit without specifying a commit message.
<summary {style='color:green;font-weight:bold'}>Check</summary>

The following commands produce this particular graph:

```text 1: git commit git commit 2: git branch bugFix git checkout bugFix 3: git branch bugFix git checkout bugFix git commit -m "Commit c2 on bugFix" git checkout main git commit -m "Commit c3 on main" git merge bugFix -m "Merge bugFix into main" 4: git checkout -b bugFix git commit -m "Commit c2 on bugFix" git checkout main git commit -m "Commit c3 on main" git checkout bugFix git rebase main ```

Optional Challenge

If you have completed Part 1 quickly, you may continue practicing with the following challenge.

Task: To continue practicing, create the following tree, which resembles a typical setup of git branches. To do this, you can open learngitbranching in a separate window.

Git branches


<summary {style='color:green;font-weight:bold'}>Check</summary>

The following commands produce this particular graph:

```text git commit git commit git checkout c1 git checkout-b hotfix git commit git checkout main git merge hotfix git checkout c1 git checkout -b dev git commit git commit git checkout c6 git checkout -b feature git commit git commit git checkout dev git merge feature git checkout main git merge dev ```

Part 2: Branching strategies

Analyze the Git graph with the different branches. Explain what happens as the project progresses.

<summary {style='color:green;font-weight:bold'}>Check</summary>

Solution

- The project has two parallel branches: main and develop. main has stable releases and urgent hotfixes (e.g., to fix bugs).

- The development branch contains the development activity, more complex tasks are completed in separate feature branches (one has been merged, another may be under development or be stalled.) Hotfixes are also integrated into the development branch.

- To release new versions, the developers create a branch from develop, do some pre-release work, and eventually merge it into main.

- This setup ensures that the main branch is stable and not affected by untested code.

Part 3: Merge methods

In this part, we focus on different methods to integrate changes from one branch into another (aka. "merge methods").

When running git merge other-branch, there are two options:

- If two branches have not diverged, Git will perform a fast-forward merge:

- A more common case is when two branches have diverged, i.e., each branch has commits that the other branch does not have. In this case, Git will create a merge commit:

In addition to git merge, users also have the option to rebase changes.

This preserves a linear version history* in the target branch instead of cluttering it with an array of merge commits:

There is another option: to squash changes from another branch. This effectively combines all changes from the other branch in a single commit, which is added on top of the target branch.

We will now practice the different methods in a real Git repository.

Important: Make sure to copy the commands and enter them in the shell as shown in the screenshot. It is not possible to run the cells in this notebook.

Task: Clone the CoLRev repository and set up the quality_model_docs branch, using the following commands.

Info The last command will reopen the codespace window and add the new project to the explorer sidebar. You will have to navigate to this notebook again.
cd /workspaces && git clone https://github.com/CoLRev-Environment/colrev
code -a /workspaces/colrev

After the restart of your Codespace, complete the setup.

The colrev repository should now be displayed in the Explorer (on the left).

cd /workspaces/colrev
git checkout 108d278e8d01a65c5128c4a880247f0272896059
git switch -c quality_model_docs
# Remove the origin for better readability of the Git viewer
git remote remove origin

Task: Go through the following options, and run the commands. Take notes on the Git graph, i.e., the structure and IDs of commits, by completing the three Git graphs (you can open the page as a PDF):

To analyze the specific changes, open the Git GUI:

Option 1: Merge commit

git switch main
git reset --hard  6f4299bdb0551c680a97dbe04b39dee51bcd0556
git merge quality_model_docs

Wait until the Git viewer is refreshed to display the merge commit and extract the commit SHAs.

Option 2: Rebase

git switch main
git reset --hard  6f4299bdb0551c680a97dbe04b39dee51bcd0556
git switch quality_model_docs
git rebase main
git switch main
git merge quality_model_docs

Option 3: Squash

git switch main
git reset --hard  6f4299bdb0551c680a97dbe04b39dee51bcd0556
git merge --squash quality_model_docs
git commit -n -m 'update docs for quality_model'

Task: Compare the three Git graphs and the commit IDs. What are the differences between the three methods in terms of the contents of commits and their metadata?

<summary {style='color:green;font-weight:bold'}>Check</summary>

Solution

- In method 1 (merge commit), there is one merge commit with two predecessors.

- In method 2 (rebase), the individual commits from the quality branch are "replayed" on top of the main branch.

- In method 3 (squash), all changes from the original quality branch are combined in a single commit, which is added on top of the main branch.

- The contents of the last commit are identical across all three methods.

- Each of the new commits has your account as the author, and the current date.

Note: All three methods change the state of the `main` branch. None changes the state of the `quality` branch. The commit-IDs in your solution will differ.

Question: Why does the merge commit always have a different ID if another student creates it or if you run the same commands a few seconds later?

<summary {style='color:green;font-weight:bold'}>Check</summary>

Answer

The commit object always contains the commit author and date. If they are different, Git generates a different commit SHA from the content and metadata.

Note: You can use the merge methods in a Codespace environment (as you just did), in a local Git repository, and even online on GitHub:

Wrap-up

🎉🎈 You have completed the Git branching notebook - good work! 🎈🎉

In this notebook, we have learned

  • To create a given Git graph using the git commit, git branch, git switch, and git merge commands
  • To explain typical branching strategies
  • The differences between merge commits, rebases, and squashed merges