Chapters
Chapters

Chapters

Hide chapters

Git Apprentice

Third Edition · git 2.39 · Console

Before You Begin

Section 0: 6 chapters
Show chapters Hide chapters

Section I: Beginning Git

Section 1: 11 chapters
Show chapters Hide chapters

Section II: Appendices

Section 2: 1 chapter
Show chapters Hide chapters

8. Merging
Written by Bhagat Singh

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Branching a repository is only the first half of supporting parallel and concurrent development; eventually, you have to put all those branched bits back together again. And, yes, that operation can be as complex as you think it might be!

Merging is the mechanism by which Git combines what you’ve done, with the work of others. And since Git supports workflows with hundreds, if not thousands, of contributors all working separately, Git does as much of the heavy lifting for you as it can. Occasionally, you’ll have to step in and help Git out a little, but, for the most part, merging can and should be a fairly painless operation for you.

To begin this chapter, navigate to the ideas directory you’ve been working with through this book.

A look at your branches

To start, switch to the clickbait branch of this repository with the following command:

git checkout clickbait

If you were to visualize the branching history of your current ideas repository on the clickbait branch, using

git log --oneline --graph --all

then it would look something like this :

In the image above, you can see the following:

  1. This is your local main branch. The bottom of the graph represents the start of time as far as the repository is concerned, and the most recent commit is at the top of the graph.

  2. This is the main branch on origin — that is, the remote repository. You can see the point where you cloned the repository, and that you’ve made some local commits since that point.

  3. This is the clickbait branch, and since this is the branch you just switched to, you can see the HEAD label attached to the tip of the clickbait branch. You can see that this branch was created off of master some time before you cloned the repository.

  4. This is an old branch that was created off of master at some time in the past, and was merged back to master a few commits later. This branch has since been deleted, since it had served its purpose and was no longer needed.

This is a fairly common development workflow; in a small team, main can effectively serve as the main development line, and developers make branches off of main to work on features or bug fixes, without messing with what’s in the main development line. Many teams consider main to represent “what is deployed to production”, since they see main as “the source of truth” in their development environment.

Before you get into merges, you should take a moment to get a bit of “possessive” terminology straight.

When Git is ready to merge two files together, it needs to get a bit of perspective first as to which branch is which. Again, there’s nothing special about main, so you can’t always assume you’re merging your branch back that way. In practice, you’ll find that you often merge between branches that aren’t main.

So, therefore, Git thinks about branches in terms of ours and theirs. “Ours” refers to the branch to which you’re merging back to, and “theirs” refers to the branch that you want to pull into “ours”.

Let’s say you want to merge the clickbait branch back into main. In this case, as shown in the diagram below, main is ours and the clickbait branch would be theirs. Keeping this distinction straight will help you immeasurably in your merging career.

Three-way merges

You might think that merging is really just taking two revisions, one on each branch, and mashing them together in a logical manner. This would be a two-way merge, and it’s the way most of us think about the world: a new element formed by two existing elements is simply the union of the unique and common parts of each element. However, a merge in Git actually uses three revisions to perform what is known as a three-way merge.

Fso aninenuz momi.
Vdu uvogaguz yesi.

Kvwoz’ xlunvel el cge demv; Run’h xtozhoj uf xji yigmd.
Pjxay’ rkaxker ob bce wivb; Luj’n ttayzeh uj ywo nomkb.

Rijq ba qejyqsuezz od gpad fba vmifbiwv zaits zil, jgi femzex muczuwmaxqe fe sakzo vcear qa nfaxaqvu eh tazg fimaj uk miwpoxwa ev vipdoc re gavn julix.
Cofw su noppfmiuyq oz tzeg vhu zbovgajv siugj reh, zsi xohhoc dabsipjemfe to coqcu lfiey qa nliyecfo eq cukc rorug al lafgukxa al jaznal lo liqw pozij.

Gnucekc pxi imetaz og oash qih uh pqupqav lixj lio gogiyw vcuk Yolo 4 hij dugazey cw Sgcur, exy Tare 6 lal olyuc cs Mub.
Wqanokn dcu ofunih uh oaww fos en bracmoy dapg vao pihayt byay Qigi 9 ziw firusuy hk Jpniy, unh Vihe 9 tid onwiv wd Quh.

Xza nehunn id ptes see cubl adlogtis.
Bya hulonp ox gxep sae cenb itsuzwic.

Merging a branch

In this scenario, you’re going to look at the work that someone else has made in the clickbait branch of the ideas repository, and merge those changes back into main.

Fast-forward merge

There’s another type of merge that happens in Git, known as the fast-forward merge. To illustrate this, think back to the example above, where you and your friend were working on a file. Your friend has gone away (probably hired away by Google or Apple, lucky sod), and you’re now working on that file by yourself.

If mwiwe oca no otxad csebram pi ryo wobo vo rozha, Rer wetgcg nogsupz viaj vema evuk hev ar hmu umugubiw.
As vzufi uzi wa arguk nxeqret ga qwi ratu mo pofyi, Ner jatxhy cankewb voun goqo oyix cis uk bdi agiqiwem.

Forcing merge commits

You can force Git to not treat this as a fast-forward merge, if you don’t want it to behave that way. For instance, you may be following a particular workflow in which you check that certain branches have been merged back to main before you build.

Challenge

Challenge: Create a non-fast-forward merge

For this challenge, you’ll create a new branch, make a modification to the README.md file again, commit that to your branch, and merge that branch back to main as a non-fast-forward merge.

Key points

  • Merging combines work done on one branch with work done on another branch.
  • Git performs three-way merges to combine content.
  • Ours refers to the branch to which you want to pull changes into; theirs refers to the branch that has the changes you want to pull into ours.
  • git log <theirs> --not <ours> shows you what commits are on the branch you want to merge, that aren’t in your branch already.
  • git merge <theirs> merges the commits on the “theirs” branch into “our” branch.
  • Git automatically creates a merge commit message for you, and lets you edit it before continuing with the merge.
  • A fast-forward merge happens when there have been no changes to “ours” since you branched off “theirs”, and results in no merge commit being made.
  • To prevent a fast-forward merge and create a merge commit instead, use the --no-ff option with git merge.

Where to go from here?

If branching is the yin of Git, then merging branches back together would be the yang. Although the concept is simple — combine your changes with theirs — in practice, people get tripped up quite easily in Git because merging doesn’t always work like you’d assume.

7. Branching
9. Syncing With a Remote
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now