In my initial years doing web development, something weird that used to happen to the team was that sometimes when doing git merge changes would go missing.
This caused the affected pals to be wary of git even to the point of thinking not to use it.
It wasn't until last year(Q4) that I really understood how rebasing works and why that situation happened.
So, I really agree with you that *neither rebase or merge are the right way but rebasing is the way to prevent merges that "remove" code.
How come?
Well, if two devs modify same file, same lines and Dev A pushes to master and then Dev B pulls, if it doesn't do a merge conflict git will remove Dev B changes and place Dev A ones.
I don't really recall the exact conditions for this to happen but it's something like this.
This is when rebasing comes in hand because it kind of respects the commit history and moves rebased commits to the beginning/tip.
Currently, I mostly use git merge but when I feel that situation could happen, I go with git rebase.
In my initial years doing web development, something weird that used to happen to the team was that sometimes when doing
git mergechanges would go missing.This caused the affected pals to be wary of git even to the point of thinking not to use it.
It wasn't until last year(Q4) that I really understood how rebasing works and why that situation happened.
So, I really agree with you that *neither rebase or merge are the right way but rebasing is the way to prevent merges that "remove" code.
How come?
Well, if two devs modify same file, same lines and Dev A pushes to master and then Dev B pulls, if it doesn't do a merge conflict git will remove Dev B changes and place Dev A ones.
This is when rebasing comes in hand because it kind of respects the commit history and moves rebased commits to the beginning/tip.
Currently, I mostly use
git mergebut when I feel that situation could happen, I go withgit rebase.👍🏾👍🏾
No way git loses commits(!) by simply merging. That only happens if Dev B hasn't commited.