You must log in or register to comment.
I usually merge because I like to see commit history as it happened and because rebasing multiple commits with conflicts is more time-consuming than fixing it in one merge commit.
I do rebase smaller changes though to reduce merge commit clutter and like interactive rebase to clean up my local commit mess before pushing.
If the changes are small enough I just do
rebase -Xtheirs main, and look to see if anything looks fucky (git diff main..).I create a new branch locally with git switch --create, pull everything from main, sacrifice a small squirrel, and run the project to make sure everything still works.
If something doesn’t work or I can’t figure out how to resolve conflicts, I quietly switch back to my previous branch like nothing happened. That problem is for future me.
You can just undo the last commit with
git reset --soft HEAD~1
The little median in the middle is the dev who helps them fix their branch over screenshare
Curious question: how many people work on one repo/module/service at your workplace or organization?
I have been vomiting blood since day1 because of merge conflicts everywhere… I’m still trying to get better at git to make my life easier.
About 20 developers on one repo in my case, we use a rebase merge strategy with fairly small feature branches so I think that helps keep merge conflicts down. Another thing is our codebase is LARGE, so changes don’t often conflict.
I see… No one cares here and everyone just merges randomly. We have about 20 people working on one repo as well but a lot of times it’s the changes to the same file 😭
