You could do a rebase interactive: git checkout new_feature git rebase –interactive old_feature and drop B1: you simply delete the line with B1: # If you remove a line here THAT COMMIT WILL BE LOST
This depends in part how you’ve done your 100+ commits and what’s been happening in the meantime. Four strategies might be useful: Reduce the number of commits to rebase If you have a beautiful clear stream of 100 commits that never modify the same code twice, I’m sorry, but you are stuck. However, from 100 … Read more
Use the BFG Repo-Cleaner, a simpler, faster alternative to git-filter-branch, specifically designed for removing unwanted files from Git history. Carefully follow the usage instructions. The core part is just this: java -jar bfg.jar –strip-blobs-bigger-than 100M my-repo.git Any files over 100 MB in size (that aren’t in your latest commit) will be removed from your Git … Read more
Git makes it hard to lose work. Run: git reflog Than look for the commit that was just before the rebase Then check it out git checkout <sha> Look around, is it the version you wanted to recover? If so, create a branch here git checkout -b mybranch
To integrate one branch into another, you have to either merge or rebase. Since it’s only safe to rebase commits that aren’t referenced anywhere else (not merged to other local branches; not pushed to any remote), it’s generally better to merge. If your feature branch is purely local, you can rebase it on top of … Read more
Use interactive rebase. For example, to go back 5 commits: git rebase -i HEAD~5 Then in the editor which pops up, delete the line containing the commit you want to remove.
The easiest way to do what you want is to stay on (or re-checkout) the branch that you want to edit and run something like this. git rebase –onto <sha1-of-bad-commit>^ <sha1-of-bad-commit> This will rebase everything since the bad commit onto the bad commit’s parent, effectively removing the bad commiit from your current branch’s history. Of … Read more
The problem is that when sublimetext2 is started, it doesn’t block and immediately returns. Git then thinks that you’re done editing the file and performs the rebase. That’s why you see the Successfully rebased and updated refs/heads/staging message, before you even edited the file. Use the subl command instead, which is designed for such use. … Read more
Try specifying exactly what remote branch you want to pull: git pull –rebase origin branch Alternatively you can also git fetch all changes from the remote repository first, and then rebase manually: git rebase origin/branch
Seems like running: git commit –allow-empty git rebase –continue Creates 2 squashed commits, instead of one. Running git rebase -i some-hash allows me to squash the 2 new commits into one.