From 17a6c0be070c4ee0edc121b83a1c9f1cb2687b91 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Fri, 6 Dec 2024 23:59:23 +0100 Subject: [PATCH] squashing: recommend --keep-base when squashing without a conflict (#2157) --- src/git.md | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/src/git.md b/src/git.md index 84f980127..177495b53 100644 --- a/src/git.md +++ b/src/git.md @@ -358,13 +358,24 @@ To avoid merges as per the [No-Merge Policy](#no-merge-policy), you may want to to ensure that Git doesn't create merge commits when `git pull`ing, without needing to pass `--ff-only` or `--rebase` every time. -You can also `git push --force-with-lease` from master to keep your fork's master in sync with -upstream. +You can also `git push --force-with-lease` from master to double-check that your +feature branches are in sync with their state on the Github side. ## Advanced Rebasing ### Squash your commits +"Squashing" commits into each other causes them to be merged into a single +commit. Both the upside and downside of this is that it simplifies the history. +On the one hand, you lose track of the steps in which changes were made, but +the history becomes easier to work with. + +If there are no conflicts and you are just squashing to clean up the history, +use `git rebase --interactive --keep-base master`. This keeps the fork point +of your PR the same, making it easier to review the diff of what happened +across your rebases. + +Squashing can also be useful as part of conflict resolution. If your branch contains multiple consecutive rewrites of the same code, or if the rebase conflicts are extremely severe, you can use `git rebase --interactive master` to gain more control over the process. This @@ -375,17 +386,12 @@ Alternatively, you can sacrifice the commit history like this: ``` # squash all the changes into one commit so you only have to worry about conflicts once -git rebase -i $(git merge-base master HEAD) # and squash all changes along the way +git rebase -i --keep-base master # and squash all changes along the way git rebase master # fix all merge conflicts git rebase --continue ``` -"Squashing" commits into each other causes them to be merged into a single -commit. Both the upside and downside of this is that it simplifies the history. -On the one hand, you lose track of the steps in which changes were made, but -the history becomes easier to work with. - You also may want to squash just the last few commits together, possibly because they only represent "fixups" and not real changes. For example, `git rebase --interactive HEAD~2` will allow you to edit the two commits only.