mirror
/
rustc-dev-guide
mirror of https://github.com/rust-lang/rustc-dev-guide.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

squashing: recommend --keep-base when squashing without a conflict (#2157)

This commit is contained in:
Ralf Jung 2024-12-06 23:59:23 +01:00 committed by GitHub
parent 1f851c0fc5
commit fcadf9608b
1 changed files with 14 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
src/git.md
View File

@ -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 to ensure that Git doesn't create merge commits when `git pull`ing, without
needing to pass `--ff-only` or `--rebase` every time. 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 You can also `git push --force-with-lease` from master to double-check that your
upstream. feature branches are in sync with their state on the Github side.
## Advanced Rebasing ## Advanced Rebasing
### Squash your commits ### 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 If your branch contains multiple consecutive rewrites of the same code, or if
the rebase conflicts are extremely severe, you can use the rebase conflicts are extremely severe, you can use
`git rebase --interactive master` to gain more control over the process. This `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 # 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 git rebase master
# fix all merge conflicts # fix all merge conflicts
git rebase --continue 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 You also may want to squash just the last few commits together, possibly
because they only represent "fixups" and not real changes. For example, 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. `git rebase --interactive HEAD~2` will allow you to edit the two commits only.