Rebase, Clean History and Team Workflows

Lesson 2 joined branches with merge. This lesson shows the other tool, rebase, and why teams choose between them. Then we clean a branch with an interactive rebase (run here without an editor), push it safely with --force-with-lease, and look at the team side: which branching workflow to use, how to protect main on GitHub, how CODEOWNERS works, and a short GitHub Actions file explained line by line.

For Git questions in interviews (merge vs rebase, recovery, monorepos) see Full-Stack Lesson 24. For CI/CD from the deployment side, see DevOps Lesson 14 (CI/CD with GitHub Actions).

Words used in this lesson

• To rebase is to take your commits and replay them, one by one, on top of a different base commit. The replayed commits are new commits with new hashes.
• Interactive rebase (git rebase -i) lets you edit the list of commits first: reorder, reword, squash, drop.
• To squash is to merge several commits into one. To fixup is the same but the message of the later commit is thrown away.
• A force push overwrites the remote branch even if it is not a fast-forward. --force-with-lease is a safer version that checks first.
• Linear history means a straight line of commits with no merge commits.
• Trunk-based development is a workflow where everyone merges small changes into one main branch ("trunk") very often.
• Branch protection is a GitHub setting that adds rules to a branch, such as "needs a review" or "checks must pass".
• CODEOWNERS is a file that says who owns which paths, so they get asked to review changes there.
• CI (continuous integration) means a server runs tests on every change automatically.
• A workflow (GitHub Actions) is a YAML file that describes what to run and when.

Rebase: a different way to join work

You have a feature branch and main moved on. A merge makes a diamond. A rebase moves your commits to start from the tip of main:

git log --oneline --graph --all     # beforegit rebase maingit log --oneline --graph --all     # after

* d1ad6f4 Add f2* 2a69f59 Add f1| * b11888f Main change 1|/* c824ea5 Base

Successfully rebased and updated refs/heads/feature.* c9d1fb7 Add f2* b0d50a6 Add f1* b11888f Main change 1* c824ea5 Base

Look at the hashes. Before: 2a69f59 and d1ad6f4. After: b0d50a6 and c9d1fb7. The content is the same, but the commits are new copies with a new parent (lesson 0: a different parent means a different hash). The old ones are not deleted; the reflog still lists them:

c9d1fb7 HEAD@{0}: rebase (finish): returning to refs/heads/featurec9d1fb7 HEAD@{1}: rebase (pick): Add f2b0d50a6 HEAD@{2}: rebase (pick): Add f1b11888f HEAD@{3}: rebase (start): checkout main

Now merging feature into main is a fast-forward, and the history is a straight line:

git switch maingit merge --ff-only feature

Updating b11888f..c9d1fb7Fast-forward

Merge or rebase?

The Pro Git book states the rule in one line: do not rebase commits that exist outside your repository and that people may have based work on. If you rebase a branch that others already pulled, they have the old commits and you have the new ones, and the next pull merges both versions and duplicates the work. Pro Git has a section called "The Perils of Rebasing" on this.

A conflict during a rebase

A rebase can conflict, as a merge can. It stops at the commit that fails:

Auto-merging f.txtCONFLICT (content): Merge conflict in f.txterror: could not apply e76c54c... Topic edithint: Resolve all conflicts manually, mark them as resolved withhint: "git add/rm <conflicted_files>", then run "git rebase --continue".hint: You can instead skip this commit: run "git rebase --skip".hint: To abort and get back to the state before "git rebase", run "git rebase --abort".

The file shows markers like a merge, but notice the sides:

<<<<<<< HEADmain=======topic>>>>>>> e76c54c (Topic edit)

HEAD (our side) is main, the base we are replaying onto. The other side is my own commit being replayed. (Lesson 2, Q10: "ours" and "theirs" flip in a rebase.) I wrote resolved in the file, ran git add f.txt, then git rebase --continue:

Successfully rebased and updated refs/heads/topic.* adf862a Topic edit* 948a742 Main edit* d766836 Base

Escape hatch: git rebase --abort returns to the state before the rebase. Because the old commits are in the reflog, a bad rebase can always be undone: git reset --hard ORIG_HEAD right after, or pick a hash from git reflog.

Interactive rebase: clean up before you share

My branch has four commits that I made while working. Only the last one deserves to be in the history:

007b4e0 Add search box0ed76a1 more wip353bd1a fix typoc224eed WIP

git rebase -i main

Git opens your editor with a to-do list (oldest first). To show it without an editor, I used a tiny script as GIT_SEQUENCE_EDITOR that prints the file. The list Git gave:

pick c224eed WIPpick 353bd1a fix typopick 0ed76a1 more wippick 007b4e0 Add search box# Rebase c824ea5..007b4e0 onto c824ea5 (4 commands)## Commands:# p, pick <commit> = use commit# r, reword <commit> = use commit, but edit the commit message# e, edit <commit> = use commit, but stop for amending# s, squash <commit> = use commit, but meld into previous commit# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous#                    commit's log message, unless -C is used, in which case#                    keep only this commit's message; -c is same as -C but#                    opens the editor# x, exec <command> = run command (the rest of the line) using shell# b, break = stop here (continue rebase later with 'git rebase --continue')# d, drop <commit> = remove commit

(I show the part of the list that Git printed; the real file has a few more comment lines.) You edit the word at the start of each line. pick keeps a commit. squash melds it into the one above. reword stops so you can change the message. drop removes it.

Squash four commits into one

I changed lines 2 to 4 from pick to squash, using sed as the sequence editor, and gave the final message through a script as GIT_EDITOR:

GIT_SEQUENCE_EDITOR="sed -i -e 2,4s/^pick/squash/" \GIT_EDITOR="sh msg.sh" git rebase -i maingit log --onelinegit log -1 --format=%B

Successfully rebased and updated refs/heads/work.b116992 Add search boxc824ea5 BaseAdd search boxCollects the query and shows matching results.

Four commits became one (b116992). The msg.sh script just wrote the message Add search box and a body line into the file Git gave it. In a real terminal you type this in the editor.

Fixup and reword

Another common pattern. After a review comment about an earlier commit, make a fixup commit that points at the commit to fix, then let Git fold it in:

git commit --fixup HEAD~1          # message becomes: fixup! Fix bugGIT_SEQUENCE_EDITOR=true git rebase -i --autosquash main

Before:                    After:94bc0c7 fixup! Fix bug     f1bcd57 Add y70513b6 Add y              496b63a Fix bug      <- now contains the fix8807be5 Fix bug            b116992 Add search box

(In the run the hashes were as in the lists; I wrote the two columns side by side by hand to compare.) --autosquash moves each fixup! commit under its target and marks it fixup. Setting GIT_SEQUENCE_EDITOR=true accepts the list without opening anything. In real life you just save and close the editor. You can turn it on for good with git config rebase.autoSquash true.

To change one message, change pick to reword for that line:

GIT_SEQUENCE_EDITOR="sed -i -e 2s/^pick/reword/" GIT_EDITOR="sh reword.sh" git rebase -i maingit log --oneline

3eacead Add y4994df2 Fix crash on empty searchb116992 Add search boxc824ea5 Base

All the commits above the reworded one got new hashes, too (Add y changed). This is lesson 0 again: change one commit and every commit after it changes.

Force push, safely

After you rebase a branch that you had already pushed (for your own pull request), the remote branch has the old commits. A normal push is rejected:

 ! [rejected]        feature -> feature (non-fast-forward)hint: Updates were rejected because the tip of your current branch is behindhint: its remote counterpart.

You must overwrite. git push --force does it blindly. If a teammate pushed to the branch in the meantime, --force silently deletes their commit. --force-with-lease is the safer option. The Git manual says it overrides the restriction "if the current value of the remote ref is the expected value", like taking a lease on the ref. By default, "expected" means what your remote-tracking branch (origin/feature) shows.

git push --force-with-lease

 + 2a69f59...6c27fc0 feature -> feature (forced update)

That worked, because nobody had touched the branch. Now my colleague Bob pushed a commit to feature, and I rewrote my local commit and tried again:

 ! [rejected]        feature -> feature (stale info)

Stale info. Git refused because the remote had a commit I had never seen. Exactly what I wanted. But look at the next step. I ran git fetch and then the same command again:

 + cf4044f...0a9ace2 feature -> feature (forced update)

It went through, and it overwrote Bob's commit. After a fetch, my origin/feature matched the server, so the "lease" was valid again, although I never looked at Bob's work. The lesson: --force-with-lease protects you only from commits you have not fetched. Do not run git fetch and force push in a reflex (some editors and tools fetch in the background, too). After a "stale info" rejection, look at git log origin/feature, and integrate what is there. You can also be exact: --force-with-lease=feature:<hash> says "overwrite only if the remote is at this hash". The same Git manual text warns that blind --force loses others' work.

Good habits: force push only your own feature branches, never main, and prefer --force-with-lease to --force. Protected branches block force pushes anyway (below).

Make pull easier

Two settings that many people turn on:

git config pull.rebase true         # pull = fetch + rebase, not mergegit config rebase.autoStash true    # stash local edits around a rebase

Team workflows

There is no single right answer. These three are common. (Pro Git, "Branching Workflows", describes the long-running and topic branch ideas. The names and the comparison below are general knowledge, not from a single source.)

How to choose:

• Deploy several times a week and have good tests? Trunk-based or short feature branches. The shorter a branch lives, the fewer conflicts and the less risk.
• Ship versions that customers install and support old releases? Release branches (a lighter form of gitflow) make sense.
• Avoid long-lived feature branches. They drift away from main, and the merge becomes a project of its own (lesson 2).

Whatever you pick, write it down in the README or CONTRIBUTING.md: how to name branches, how big a PR should be, and which merge method to use (lesson 3). Merge methods tie in: squash and merge on GitHub gives a linear main with one commit per PR. The GitHub docs also list a "Require linear history" option that blocks merge commits.

Protect the main branch (GitHub)

Not run; from the GitHub docs. A branch protection rule adds checks that cannot be skipped by accident. The docs list these settings:

When someone breaks a rule, the push is refused with a message like the docs' example remote: error: GH006: Protected branch update failed for refs/heads/main. By default, the rules do not apply to repository admins unless you enable "do not allow bypassing the above settings". The docs also describe rulesets: a newer way to define rules for many branches or tags, even across repositories in an organization, with a bypass list. Several rulesets can apply at the same time, while only one branch protection rule applies to a branch.

A sensible start for a small team: require a PR with one approval, require the CI check to pass, require conversations resolved, block force pushes. Add code owners when the team grows.

CODEOWNERS

A file named CODEOWNERS in .github/, the repository root or docs/ says who is responsible for which paths. The docs say: owners are automatically requested for review when a PR changes their files, and (with the branch protection setting) their approval can be required. Syntax follows .gitignore rules, with a pattern then one or more owners on the same line; the last matching pattern wins.

# Default owners for everything*              @acme/platform-team# Frontend code/web/          @acme/frontend# Database migrations need the data team/db/migrations/  @acme/data-team @maria# CI and release files/.github/      @acme/platform-team

Rules from the docs worth remembering: owners need write access to the repository (teams must be visible and have write access), the file is read from the base branch of the PR, it must be under 3 MB, and lines with invalid syntax are skipped. Do not use ! negation or [ ] ranges; they do not work in CODEOWNERS. CODEOWNERS only asks for review by itself. To make it a rule, switch on "Require review from Code Owners" in the protection rule. Drafts do not request owners until marked ready.

A GitHub Actions workflow, line by line

CI means a server runs your checks on every change, so a failing test blocks the merge instead of reaching main. In GitHub Actions the instructions live in a YAML file under .github/workflows/. The GitHub quickstart says the folder name is required, and the file can have any name ending in .yml or .yaml. This is a short but realistic file for a Node.js project. I did not run it (it needs GitHub). I checked only that it is valid YAML.

name: CIon:  pull_request:    branches: [main]  push:    branches: [main]permissions:  contents: readconcurrency:  group: ci-${{ github.ref }}  cancel-in-progress: truejobs:  test:    runs-on: ubuntu-latest    timeout-minutes: 10    steps:      - name: Check out the code        uses: actions/checkout@v5      - name: Set up Node.js        uses: actions/setup-node@v5        with:          node-version: 22          cache: npm      - name: Install dependencies        run: npm ci      - name: Lint        run: npm run lint      - name: Test        run: npm test

Tie it together: in branch protection, mark the test check as required. Now a PR cannot merge until lint and tests pass. In DevOps Lesson 14 you can see the same ideas extended to build and deploy steps (CI/CD with GitHub Actions).

Try it

1. In a practice repository make main with one commit, then a feature branch with two commits, then add one more commit on main. Rebase feature on main. Compare the hashes of the two feature commits before and after.
2. Make four small commits: WIP, typo, WIP 2, Add login form. Use git rebase -i to squash them into one commit called Add login form.
3. Make a mistake in a rebase (squash the wrong commits). Undo it with the reflog.
4. Create a bare repository as a remote. Push a branch, rebase it, and try to push. What happens? Then use --force-with-lease.
5. Write a CODEOWNERS file so that /docs/ is owned by @acme/writers and everything else by @acme/devs. Which line must come first?
6. In the workflow above, what would you change so the workflow also runs on pull requests to a release branch?
7. Name two settings you would turn on first for main in a team of five, and say why.

Answers

1. The two feature commits have new hashes after the rebase; the messages and content are the same. git reflog still lists the old ones.
2. git rebase -i main (or HEAD~4), change pick to squash (or fixup) on the lines for the three small commits, save, and write the final message in the second editor.
3. git reflog shows entries like rebase (start). Run git reset --hard HEAD@{N} for the line before rebase (start), or git reset --hard ORIG_HEAD immediately.
4. The push is rejected as non-fast-forward. git push --force-with-lease succeeds if nobody else pushed to that branch.
5. * @acme/devs first, then /docs/ @acme/writers. The last matching pattern wins, so the specific rule has to come after the general one.
6. Change branches: [main] under pull_request to branches: [main, release].
7. A good start: require a PR with at least one approval (so nothing is pushed straight to main), and require the CI check to pass (so broken code cannot merge). Blocking force pushes is already the default.

Interview questions

Key takeaways

• Rebase copies commits onto a new base: straight history, new hashes. Rewrite only history nobody else has.
• git rebase -i lets you pick, reword, squash, fixup or drop commits. Use it to clean your own branch before review. --autosquash folds fixup! commits in.
• After a rebase you must force push your own branch. Prefer --force-with-lease, and look before you force after a fetch.
• Pick a workflow that fits how you release: trunk-based or short feature branches for continuous delivery; release branches when you support several versions. Keep branches short-lived.
• Protect main: PR with review, required CI checks, resolved conversations, no force pushes. Add CODEOWNERS for review routing.
• A GitHub Actions workflow is a YAML file under .github/workflows/ with events (on), jobs, a runner and steps. Mark its check as required so it blocks bad merges.
• The reflog can undo almost any rebase mistake.

What's next

This is the last lesson of the series. To go further, read Full-Stack Lesson 24 for the interview view of Git and monorepos, DevOps Lesson 14 for CI/CD that deploys, and Team Lead Lesson 3 for review habits. Practise now: take a real branch, make a backup branch, tidy it with git rebase -i, and open a pull request with a description that follows the template from Lesson 3.