Merge vs rebase
Skill Amey-Thakur/AI-SKILLS/skills/git-collaboration/merge-vs-rebase
Plug-and-play skills and prompts for every AI coding agent
npx -y skills add Amey-Thakur/AI-SKILLS --skill merge-vs-rebaseAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Choose merge or rebase by the history you want, use interactive rebase safely, and set a team policy. Use when deciding integration mechanics or resolving debates about git history style.
SKILL.md
3.2 KB, 736 tokens by cl100k_base, as published. Nobody here has run it
Merge vs rebase
Merge and rebase produce the same code and different histories. The choice is about what story you want git to tell, and the one non-negotiable rule under all of it: never rebase commits that others have already pulled.
Method
- Understand what each does to history. Merge preserves the true topology (a merge commit joins two lines, showing work happened in parallel); rebase rewrites your commits onto the tip of the base, producing a straight line as if you worked sequentially. Neither changes the final code; both are valid; the disagreement is aesthetic and practical, not correctness.
- Rebase your local, in-progress branch to stay current.
git rebase mainon a branch only you have keeps it up-to-date with a clean linear history and surfaces conflicts incrementally. This is rebase's best use: private branch hygiene before it is shared or merged. - Never rebase shared history. Rebasing commits others
have based work on rewrites history they depend on,
forcing everyone into painful recovery: the one rule
that causes real damage when broken. Published commits
(on main, or on a branch a teammate pulled) are
immutable; if you must undo them,
git revert(a new commit) not rebase (see git-history-hygiene's force-push etiquette). - Pick a team integration policy and automate it.
Common choices: merge commits (full topology,
--no-ff), squash-and-merge (each PR becomes one clean commit on main: popular for readable history and bisectability), or rebase-and-merge (linear, preserves individual commits). Enforce it in the platform's merge button (see branch-strategy's protection rules); the worst outcome is a mix nobody can read. - Use interactive rebase to curate before sharing.
git rebase -ito squash fixup commits, reorder, and reword into a coherent sequence before opening the PR or merging (see git-history-hygiene's atomic-commit goal): the reviewer reads intent, not your keystroke log. Fixup commits plus autosquash automate the common case. - Recover safely when a rebase goes wrong. The reflog
(
git reflog) records where branches pointed before any rewrite;git reset --hard HEAD@{n}restores. Knowing this makes rebase non-scary: nothing is truly lost for ~90 days, so experimentation on local branches is safe.
Boundaries
- The choice affects readability and tooling (bisect, blame, revert), not code correctness; do not let it consume the energy a real design question deserves. Pick a policy, automate it, move on.
- Squash-and-merge simplifies main but loses intermediate commits (and their granular bisect/blame value): a reasonable trade for most teams, a loss for those who curate meaningful commit series (see git-history-hygiene).
- The never-rebase-shared rule has no exceptions worth the risk; when tempted, revert forward instead, and if a shared branch truly must be rewritten, coordinate explicitly and expect pain.