Part III · Shell and commands

30.3 Merge or rebase?

alsomergerebasegit mergegit rebasemerge conflictconflictconflictsfast-forwardinteractive rebasesquashcherry-pickgit cherry-pick

TL;DR

Both bring another branch's work into yours. Merge adds a commit with two parents and keeps history as it happened. Rebase replays your commits on top of the other branch: a straight line.
Rebase gives your commits new hashes. Rebase only commits nobody else has: your local or personal branches.
A conflict means both sides changed the same lines: edit the file, git add it, then continue.

git merge main                 # or: git rebase main
git status                     # files in conflict
git merge --continue           # or: git rebase --continue / --abort

On your machine

alice@laptopexample

$ atfq 30.3
  Files     /etc/gitconfig, ~/.gitconfig
  Identity  name and email set
  Settings  init.defaultbranch = main
            pull.rebase = true
            core.autocrlf = input
            credential.helper = store (passwords in plain text in
            ~/.git-credentials)
  Aliases   st, lg
  Includes  1 more file, read under conditions (include, includeIf)

An example: Alice's laptop, one of the test machines. In your terminal, this block shows your own machine, read live.

Pitfalls

After rebasing a branch you already pushed, a plain push is rejected; ⚠ git push --force-with-lease replaces it, and breaks others' copies.
git rebase -i main lets you squash, reorder or reword commits before sharing them; don't do it on shared history.
Conflict markers left in a file (<<<<<<<) still commit: search for them before git add.
merge.conflictstyle = zdiff3 shows the common ancestor in conflicts: much easier to resolve.

Deep dive 2 questions

What is a fast-forward?

If your branch has no commits the other lacks, there's nothing to merge: git just moves your branch forward to the other's commit, with no merge commit. That's what happens on git pull when you hadn't committed locally. --no-ff forces a merge commit anyway, to keep a feature visible as a group.

Then which one?

Many teams rebase their own branch on the main one to keep it current and readable, then merge it in (or squash it into one commit) through a pull request. The rule that matters: never rewrite history that someone else has based work on.

Commands: git
See also: 30.1 How git stores your work
30.4 Remotes: fetch, pull and push
30.2 Undoing things in git