In the last two lessons, combining branches meant merging, and a diverged history earned a merge commit. That’s honest and safe, but on a busy repository git log --graph starts to look like a train map. Rebasing is the other way to combine work: instead of joining two lines, it moves your line so there’s only one.
Your projects-grid branch split from main at b2. Since then main gained c3 and your branch has d4 and e5. From the branch, run:
git switch projects-grid\ngit rebase mainSuccessfully rebased and updated refs/heads/projects-grid.Git found the commits on your branch that aren’t on main (d4, e5), set them aside, moved your branch to main’s tip, and replayed each change on top, one commit at a time.
The replayed commits are new commits. Same changes and messages, different parents, so different IDs. That’s not a detail; it’s the whole story of when rebase is safe. A commit’s ID includes its parent, so you can’t move a commit, only make a copy somewhere else.
\nNow main is an ancestor of your branch, so bringing the work in is a fast-forward:
git switch main\ngit merge projects-grid # Fast-forwardHistory is a straight line, as if you’d started the grid after the typo fix.
\nBecause rebase replays commits one at a time, a conflict stops it at a specific commit. The routine is the one you learned for merges, with different words at the end:
\n# Git stops: CONFLICT (content): Merge conflict in projects.html\n# edit projects.html, remove the markers, check it\ngit add projects.html\ngit rebase --continue # finish this commit, replay the nextgit rebase --abort returns the branch to exactly where it was before you started. git rebase --skip drops the commit that’s conflicting, which is rarely what you want.
One surprise: during a rebase, “ours” and “theirs” swap. You’re replaying your commits onto main, so HEAD (the top half of a conflict) is main’s side, and your commit is the bottom half. Read the labels, not your instincts.
Before you share a branch, you can rewrite its commits. git rebase -i opens a to-do list in your editor:
git rebase -i mainpick 4b1e2c0 Add projects grid\npick 9a3d7f1 fix typo\npick c2e8b44 Grid gap on mobileChange a word in front of a commit and save. reword edits its message, squash or fixup folds it into the commit above (keeping or discarding its message), drop deletes it, and reordering lines reorders commits. Changing pick 9a3d7f1 to fixup 9a3d7f1 turns three commits into two clean ones. This is how professionals keep “fix typo” commits out of a pull request.
Rebasing replaces commits with copies. That’s harmless when you’re the only one who has them. It’s a mess when someone else has already built on the originals: their history still contains d4 and e5, yours contains d4' and e5', and the next pull produces duplicate commits and baffling conflicts.
So: don’t rebase commits that exist outside your repository and that people may have based work on. In practice:
\nmain or any branch other people pull from.git push --force-with-lease--force-with-lease overwrites the remote branch only if it still points where you last saw it. If a teammate pushed in the meantime, it refuses instead of erasing their work.
| \n | Merge | \nRebase | \n
|---|---|---|
| History | \nTrue record, with merge commits | \nLinear, as if work were sequential | \n
| Commit IDs | \nUnchanged | \nRewritten | \n
| Safe on shared branches | \nYes | \nNo | \n
| Conflicts | \nResolved once | \nMay recur per replayed commit | \n
A sensible default: rebase your own feature branch onto main to stay current and tidy it before review; merge (often through a pull request) to land it. Many teams also set git pull to rebase your unpushed commits, which you’ll configure in the next section, when your portfolio finally gets a remote.
git rebase main replays your branch’s commits on top of main’s tip, creating new commits with new IDs.","After a rebase, merging the branch into main is a fast-forward, so history stays a straight line.","During a rebase conflict, fix the file, git add it, then git rebase --continue; git rebase --abort undoes the whole rebase.","The golden rule is to never rebase commits that other people may have already built on; rebase only your own unshared work.","If you must update a branch you already pushed, use git push --force-with-lease, never a plain --force."],"further":[{"title":"Rebasing (Pro Git)","url":"https://git-scm.com/book/en/v2/Git-Branching-Rebasing"},{"title":"git rebase reference","url":"https://git-scm.com/docs/git-rebase"},{"title":"About Git rebase (GitHub Docs)","url":"https://docs.github.com/en/get-started/using-git/about-git-rebase"}],"quiz":[{"q":"Your branch projects-grid has commits d4 and e5. You run git rebase main on it. What happens to d4 and e5?
main’s tip.","why":"Commits can’t move, because a commit’s ID includes its parent. New parent means a new commit."},{"text":"They’re merged into one commit on main.","why":"Rebase doesn’t squash by default and doesn’t touch main. It rewrites the branch you’re on."},{"text":"Git creates new commits with the same changes on top of main; the branch points to those, and the originals become unreferenced.","why":"Correct. The replayed commits (often written d4' and e5') have new IDs. The originals are still in the reflog for a while."},{"text":"They’re deleted and you have to recommit the work.","why":"Rebase replays your changes automatically. Nothing needs to be redone by hand unless there’s a conflict."}],"answer":2},{"q":"Mid-rebase, Git reports a conflict in projects.html. You’ve edited the file into shape. What do you run next?
git commit -m "Fix conflict"","why":"During a rebase, Git makes the commits itself. Committing by hand adds an extra commit and confuses the replay."},{"text":"git add projects.html, then git rebase --continue","why":"Correct. Staging marks the conflict resolved; --continue finishes that commit and replays the rest."},{"text":"git merge --continue","why":"You’re in a rebase, not a merge. Each operation has its own continue command."},{"text":"git rebase main again from the start","why":"A rebase is already in progress, so Git refuses to start another. Continue or abort the current one."}],"answer":1},{"q":"Which situation breaks the golden rule of rebasing?
","options":[{"text":"Rebasing your local, never-pushedfooter branch onto main.","why":"Nobody else has these commits, so rewriting them affects only you. This is rebase’s ideal use."},{"text":"Using git rebase -i HEAD~3 to squash typo fixes before opening a pull request.","why":"Tidying your own unshared commits is exactly what interactive rebase is for."},{"text":"Running git pull --rebase to put your unpushed commits after your teammates’ new ones.","why":"That rewrites only your local, unpushed commits, so it’s safe and common."},{"text":"Rebasing the shared main branch and force-pushing it while teammates have work built on it.","why":"Correct. Their commits sit on top of the old IDs you just replaced, so their next pull produces duplicates and confusing conflicts."}],"answer":3},{"q":"You rebased your own pull request branch, and git push is now rejected as non-fast-forward. What’s the safe way to update it?
git push --force-with-lease","why":"Correct. It overwrites the remote branch only if it’s still where you last saw it, so you won’t silently wipe out a commit someone else pushed since your last fetch."},{"text":"git push --force","why":"That overwrites the remote no matter what, including commits a reviewer pushed since your last fetch."},{"text":"git pull and then push.","why":"Pulling merges the old commits back in next to their rebased copies, leaving duplicates in the branch."}],"answer":0}],"exercise":{"kind":"fill","language":"bash","template":"git switch projects-grid\ngit {{0}} main # replay my commits on top of main\n# CONFLICT in projects.html: edit it, then\ngit add projects.html\ngit rebase {{1}} # replay the remaining commits\n\n# this branch was already pushed for review, so update it safely\ngit push {{2}}","blanks":[{"answers":["rebase"]},{"answers":["--continue"]},{"answers":["--force-with-lease"]}],"title":"Rebase the projects grid","prompt":"Your projects-grid branch is behind main, and you want a linear history. Fill in the blanks to rebase it, get through one conflict, and update the branch you already pushed for review without risking anyone else’s commits.
git add, a rebase in progress needs one more word to keep going.","There’s a force-push option that checks the remote hasn’t changed since you last fetched. It’s long; it includes the word lease."],"explanation":"git rebase main replays the branch’s commits on top of main’s tip. When a replayed commit conflicts, you fix the file, git add it and run git rebase --continue (or --abort to give up). The rebased commits have new IDs, so a normal push is rejected; git push --force-with-lease replaces the remote branch only if nobody pushed to it since you last looked. This is fine on your own review branch, and never on main.