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)
+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?
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
thanks for posting and making the video! great explanation. seems like
git rebaseis cleaner and maybe preferred?what are some example situations when
git mergeis 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)The trick is that the statement "don't use rebase on shared branches" is just wrong.
What do you mean by "is just wrong"? You suggest using rebase also on shared branches? Can you elaborate?
+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?
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.