The problem with interactive rebasing is that you’re replaying your commits one at a time. When one of your past commits can’t be merged automatically due to conflicts, you’ll be resolving conflicts from an old commit and it will be difficult because you have moved on since then. Subsequent commits are likely to be conflicted as well. It ends up becoming merge hell.
Fortunately there’s an alternative to interactive rebase when you want to squash all your commits into one and rebase on the latest mainline branch commit (assuming develop is the mainline branch):
git fetch
git merge origin/develop
You may have conflicts at this point, but they will be conflicts between your latest work and latest develop commit. If so, resolve them and git commit.
But when you are using rebase to have self contained commits (target a single objective) you end up with fewer conflicts on top of your commits. You still get conflicts, but they're a lot easier to deal with.
Refactoring creates the biggest source of conflict management. But these are things you want to be short lived. It encourages that whole CI thing. It can be a pain, but don't avoid refactoring code you work on.
If you have moved on from your old commits you aren't following good CI practices, I think what you may be referring is that you have identified the direction you're actually taking and your latest approach supercede those other commits. In which case, your squash suggestion is appropriate.
The problem with interactive rebasing is that you’re replaying your commits one at a time. When one of your past commits can’t be merged automatically due to conflicts, you’ll be resolving conflicts from an old commit and it will be difficult because you have moved on since then. Subsequent commits are likely to be conflicted as well. It ends up becoming merge hell.
Fortunately there’s an alternative to interactive rebase when you want to squash all your commits into one and rebase on the latest mainline branch commit (assuming
developis the mainline branch):You may have conflicts at this point, but they will be conflicts between your latest work and latest
developcommit. If so, resolve them andgit commit.Now do the following:
And now you’re exactly one commit ahead of
origin/develop.But when you are using rebase to have self contained commits (target a single objective) you end up with fewer conflicts on top of your commits. You still get conflicts, but they're a lot easier to deal with.
Refactoring creates the biggest source of conflict management. But these are things you want to be short lived. It encourages that whole CI thing. It can be a pain, but don't avoid refactoring code you work on.
If you have moved on from your old commits you aren't following good CI practices, I think what you may be referring is that you have identified the direction you're actually taking and your latest approach supercede those other commits. In which case, your squash suggestion is appropriate.
But im generally not that disaplined
Git is a Communication tool
Jesse Phillips ・ Dec 12 '18 ・ 2 min read