Timeline for How do I squash my last N commits together?
Current License: CC BY-SA 4.0
53 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 15 at 13:48 | review | Suggested edits | |||
| Jun 17 at 1:59 | |||||
| May 7 at 2:14 | comment | added | Turtles Are Cute | When I do this, I end up with a single commit, but a huge list of changed files, in addition to the ones I actually changed! | |
| Apr 9 at 13:54 | comment | added | grenix | If you used the same commit message more than once then git commit --edit -m"$(git log --format=%B --reverse HEAD..HEAD@{1} | sort -u)" might also make sense | |
| Mar 25 at 12:47 | history | edited | qoomon | CC BY-SA 4.0 |
we should teach people to always use --force-with-lease instead if --force
|
| S Jan 25 at 19:59 | history | suggested | unrealapex | CC BY-SA 4.0 |
Remove unnessicary AND
|
| Jan 24 at 8:47 | review | Suggested edits | |||
| S Jan 25 at 19:59 | |||||
| Oct 12, 2023 at 23:20 | history | edited | Dan Ciborowski - MSFT | CC BY-SA 4.0 |
added 8 characters in body
|
| Oct 11, 2023 at 10:19 | comment | added | Sumax |
Thanks for clarifying this about -f: "and always fully define your target".
|
|
| Sep 29, 2023 at 22:18 | history | edited | Dan Ciborowski - MSFT | CC BY-SA 4.0 |
adding info on git --force
|
| Aug 4, 2023 at 22:23 | history | edited | Benjamin Loison | CC BY-SA 4.0 |
Add Shell syntax highlighting
|
| Aug 18, 2022 at 14:01 | comment | added | Rafaël Moser |
And you can quit the editor by pressing ESCand typing :wq!
|
|
| Jul 12, 2022 at 15:26 | comment | added | eric_kernfeld |
I regret upvoting this because it put my repo into a strange state that misbehaves under my normal (very simple) workflow. git pull, git push, now I have N+2 commits instead of N. The log looked normal so as a novice, this feels like a booby trap.
|
|
| Oct 25, 2021 at 8:00 | comment | added | bebbo | you'll end up losing information and history if files were moved around. You should use the correct approach mentioned from @user1376350 | |
| Jul 5, 2021 at 14:24 | comment | added | Srini Karthikeyan | What if code push has already been done and I want to remove previous commits from history. Will it work? | |
| Apr 17, 2021 at 23:53 | comment | added | Jake |
@MatthiasM re "git push -f sound dangerous. Take care to only squash local commits. Never touch pushed commits!" Depends on your workflow and context. Using GitHub it is normal (actually required) to have to git push -f after a rebase of a branch. This may be no different. If you're working on your own branch for a PR, there's no problem. Also, you cannot force-push to a protected branch (like main on GitHub). So there's no danger if your project is set up right.
|
|
| Feb 18, 2020 at 14:28 | comment | added | Brian Pursley |
Leaving this here in case it helps someone. Using bash, I just define a function squash() { git reset --soft HEAD~$1; git commit --edit -m"$(git log --format=%B --reverse HEAD..HEAD@{1})"; } and then I can just say squash 2 or squash 3.
|
|
| Nov 11, 2019 at 21:34 | comment | added | Varun Singh | Put this in your bashrc for an alias to squash the last two commits together, using the message of the first commit --> alias gsquash="git reset --soft HEAD~2 && git commit --edit -m\"$(git log --format=%B HEAD@{0}..HEAD@{2})\"" # Squash last two commits together, using message of first commit. | |
| Oct 23, 2019 at 0:05 | comment | added | RTHarston |
This worked for me where the git rebase -i did not. I was trying to squash some work that had a couple of merge commits thrown in the middle and I kept running in to conflicts (I didn't think that was possible, but I'm guessing it was because of the merge commits that were removed). Tried this and voila! No complaints, worked first time. Highly recommended. :)
|
|
| Oct 9, 2019 at 10:50 | comment | added | joel |
If my current branch has branched off 'otherbranch', and I want to squash everything I did on the current branch before I merge it into 'otherbranch', I can do git reset --soft otherbranch rather than having to work out how many commits ago that was
|
|
| Jul 12, 2019 at 21:53 | comment | added | dyslexicanaboko | If you want to target a commit specifically you can do so by providing the hash, but it wasn't as simple as replacing the index with the hash. I got this by using Source Tree: git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks reset -q --soft <Your SHA here> git commit The hash that should be provided though should be the commit just before your target. | |
| Jun 19, 2019 at 1:57 | comment | added | cowlinator |
For those curious about HEAD..HEAD@{1}, r1..r2 specifies a range of commits that are reachable from r2 excluding those that are reachable from r1, and <refname>@{<n>} specifies the n-th prior value of that ref. So here, HEAD..HEAD@{1} means all the commits between the current HEAD and where HEAD was right before the reset.
|
|
| Apr 17, 2019 at 23:34 | comment | added | Zach Saucier |
I accidentally did git reset --soft HEAD~3 twice. Be aware that they stack.
|
|
| Mar 25, 2019 at 22:18 | comment | added | Chiramisu |
@AdrianRatnapala I've not tried it yet, but EthanB added an answer below, based on this one, to do something like that using .gitconfig.
|
|
| Mar 4, 2019 at 15:10 | comment | added | Kyle Krzeski |
Don't forget + if your other commits were already pushed to remote - i.e. git push origin +name-of-branch
|
|
| Mar 2, 2019 at 10:29 | comment | added | rockdaboot |
Try to get used to git push --force-with-lease instead of git push -f !
|
|
| Feb 14, 2019 at 19:13 | comment | added | ColinM |
Not sure what version this was added in but you can use this one liner to reliably reuse the latest commit message and author: git reset --soft {base-commit} && git commit --reuse=HEAD@{1}
|
|
| Feb 5, 2019 at 21:38 | comment | added | Raphael | A noteworthy difference between this approach and "real" rebase is that the authors of the original commits are lost here. | |
| Jan 15, 2019 at 13:09 | comment | added | Cyker | I thik this is currently the best method. But watch our for its caveat: If you have unstaged or uncommitted changes, Git won't stop you from performing these operations, and your uncommitted changes will get merged into the squashed commit. This probably is or is not what you want. | |
| Jun 21, 2018 at 16:05 | comment | added | mageos | If you have already pushed the commits that you are squashing and you want to avoid having to do a force push, create a new branch at the commit you are at and push it: git checkout -b new-branch-name && git push -u | |
| Apr 17, 2018 at 13:07 | comment | added | moodboom |
Having to git push -f is always a requirement after rewriting history. It CAN be bad to rewrite history, certainly if you are doing it to a shared repository. But that's a separate subject not related to this answer (which is great).
|
|
| Mar 29, 2018 at 15:34 | comment | added | rsmith54 |
I think better than those saying to force push is to just make a new feature branch. So something like git checkout -b feature-name-squashed, follow these directions, then push the new squashed version of the branch. If you do this, you will have access to the full commit logs of the feature (on feature-name) if you ever need them.
|
|
| Nov 16, 2017 at 6:49 | comment | added | Tyrone Wilson |
I put this into ~/bin/git-funge as a script because we have to have single commit messages on pull requests. Now I just write git funge HEAD~3 and edit my messages to suite a single PR message and save and it is all sorted. :) Thanks for a great answer. (funge is my way of meaning fungible but reads better as a verb :P)
|
|
| Jul 13, 2017 at 8:13 | comment | added | Tom Russell |
git push -f doesn't appear to alter the commit log of the upsteam repository.
|
|
| Jun 14, 2017 at 12:31 | comment | added | soMuchToLearnAndShare | the git reset --soft HEAD~3 definitely is better in terms of number of conflicts to solve. our test case was HEAD~6, but one of the commit was a merge commit, so we had 45 commits and the rebase -i HEAD~6 gave us so many conflicts which end up failing the build. And when we used reset --soft it gave us 0 conflicts to solve. | |
| Apr 11, 2017 at 15:09 | review | Suggested edits | |||
| Apr 11, 2017 at 19:58 | |||||
| Mar 23, 2017 at 11:51 | comment | added | GreensterRox |
This helped me when git rebase --interactive was giving me error: could not apply. Possibly because one of the commits I was trying to squash was a merge with a resolved conflict.
|
|
| Oct 21, 2016 at 17:30 | comment | added | stevenhaddox |
I want to upvote this, but I can't bring myself to be the one who changes the upvoted count from 1337...
|
|
| Jul 27, 2016 at 9:33 | comment | added | Victor Sergienko |
Make sure your working copy has no other changes (git stash them or something). Otherwise, you have the chance to commit them into the squashed commit too, which might be not something you intend to do.
|
|
| Jul 21, 2016 at 0:21 | comment | added | Zach Saucier |
I also need to use git push --force afterwards so that it takes the commit
|
|
| Jul 14, 2016 at 12:53 | comment | added | vikramvi | after doing this while trying to push getting error error: failed to push some refs to '[email protected]:....' hint: Updates were rejected because the tip of your current branch is behind. I found how to solve this here: stackoverflow.com/questions/5667884/… | |
| Oct 13, 2015 at 18:13 | review | Suggested edits | |||
| Oct 13, 2015 at 18:38 | |||||
| Sep 24, 2015 at 14:49 | comment | added | Matthias M | @2rs2ts git push -f sound dangerous. Take care to only squash local commits. Never touch pushed commits! | |
| Mar 19, 2015 at 14:40 | history | edited | iwasrobbed | CC BY-SA 3.0 |
added 50 characters in body
|
| Jan 7, 2015 at 17:12 | comment | added | Mark K Cowan |
git log --one-line or something like that will display a list of commit IDs and messages, one per line. Very useful with this solution.
|
|
| Nov 12, 2014 at 14:24 | comment | added | sschuberth |
Here's an alias in case you'd like to fixup instead of squash: fixup = "!f() { base=${1:-2}; git reset --soft HEAD~$base && git commit -C ORIG_HEAD~$(expr $base - 1); }; f".
|
|
| Oct 29, 2014 at 23:32 | comment | added | 2rs2ts |
This kinda-sorta required me to push -f but otherwise it was lovely, thanks.
|
|
| Jun 3, 2014 at 15:02 | comment | added | n8tr | I like this solution in general but like providing my own commit message. Here is a solution that sets up an alias so that you can do git squash 3 'my commit message' | |
| Apr 23, 2014 at 6:13 | comment | added | Chris Johnsen |
@A-B-B: If your branch has an “upstream” set, then you may be able to use branch@{upstream} (or just @{upstream} for the current branch; in both cases, the last part can be abbreviated to @{u}; see gitrevisions). This may differ from your “last pushed commit” (e.g. if someone else pushed something that built atop your most recent push and then you fetched that), but seems like it might be close to what you want.
|
|
| Apr 22, 2014 at 18:45 | comment | added | Asclepius |
When doing the soft reset, what's the best way to auto-determine the target commit id, i.e. of the last pushed commit? I don't want to have to lookup and count 3, for example.
|
|
| Nov 8, 2013 at 17:50 | comment | added | Adrian Ratnapala |
Ha! I like this method. It is the one closes to the spirit of the problem. It's a pity that it requires so much voodoo. Something like this should be added to one of the basic commands. Possibly git rebase --squash-recent, or even git commit --amend-many.
|
|
| Mar 5, 2011 at 4:30 | history | edited | Chris Johnsen | CC BY-SA 2.5 |
edited body
|
| Mar 5, 2011 at 4:25 | history | edited | Chris Johnsen | CC BY-SA 2.5 |
added 349 characters in body; added 61 characters in body; added 13 characters in body
|
| Mar 5, 2011 at 4:19 | history | answered | Chris Johnsen | CC BY-SA 2.5 |