loading...

re: Git Rebase vs Merge VIEW POST

FULL DISCUSSION
 

thanks for posting and making the video! great explanation. seems like git rebase is cleaner and maybe preferred?
what are some example situations when git merge is the better method to go with? (other than the example you mentioned in the video when you're not the only working on a feature branch)

 

It's not "cleaner" or "preferred" 🙂. It's another option to "git merge".

Rebasing (for merging) is basically always preferred when you want to have a linear git commit history. On the other side, if you're following branching models like "git flow" then that's probably not what you want, as that strategy suggests to keep merge commits. On the other side, if you're using something like "trunk based development" (trunkbaseddevelopment.com/) then you will.

Now apart from updating feature branches etc, having a linear commit history on the main branch (i.e. master) has helped me a lot for things like "git bisect" to debug problems in a larger git based monorepository.

 

The trick is that the statement "don't use rebase on shared branches" is just wrong.

 

+1 IMO, the working branch should be rebased against the upstream. But shared branches ie. Master / or anything else similar should have merge commits.

Can you elaborate on that? If I got you right, you basically say that the feature branches should be rebased to be updated with master, but when you merge it back it, you want to use a merge commit, so use "git merge". Is that what you intended?

 

What do you mean by "is just wrong"? You suggest using rebase also on shared branches? Can you elaborate?

Code of Conduct Report abuse