Rebase Supremacy
Rebase Supremacy
You're viewing a single thread.
238 comments
-
Imagine rewring history
-
History is written by the squashers.
-
Imagine working with a tangled spaghetti of history
-
You don't? Just follow the merges.
-
-
You try to pull someone's changes, but whoops, they used rebase and rewrote history! Delete the branch and start over.
-
No you just do a rebase to bring it in. Assuming you’re making atomic commits you shouldn’t have a ton of merge conflicts. If you have to do this a lot, your branch scope is really bad and the problem isn’t in how you’re using got, it’s in how you’re slicing work.
-
If you try to pull someone else's rebased / history rewritten branch, your git will tell you that it's rejected. You can completely avoid this by merging instead of rewriting history.
-
...or you simply rebase the subset of commits of your branch onto the rewritten branch. That's like 10 simple button presses in magit.
-
-
-
2 things:
- You don't pull rebased work pretty much ever. Rebasing is for feature branches by a single author to craft a high quality history, generally. It's much, much better than littering your branch with merge commits from upstream.
- If for some reason you do need to pull rebased changes, you simply do
git pull --rebase. Works without issue.
-
-
238 comments