4 ms·
I'll often just do a git reset --hard origin/branch-name
by NewJazz 3y ago
I'll often just do a
git reset --hard origin/branch-name
- lmm 3y agoRight but that doesn't help if you've done your own work on top of their changes.
- iainmerrick 3y agoI think rebase is generally the correct approach here. If you've done your own work on top of their old changes, rebase your work on top of their new changes.
- lmm 3y agoThat's possible but it requires a bunch of manual tracking and results in wasted/duplicate effort with people resolving the same conflicts multiple times.
- cnity 3y agoJust use: > git pull --rebase
- pjc50 3y agogit config --global pull.rebase=true
- lmm 3y agoRight but assuming I have a branch that's diverged from theirs I have to do a fiddly git rebase --onto and likely resolve the same conflicts again.
- cnity 3y agoThis to me is a sign that some commits should be squashed, because it implies the same lines have changed multiple times in the commits that are ahead of the remote branch. It's worth doing the rebase interactively and squashing them up.
- xorcist 3y agoIf you find yourself fixing the same rebase conflicts over and over again, because you for some reason need to work on conflicting changes simultaneously (which is of course best avoided for other reasons), use "git rerere".
- lmm 3y agoI don't trust rerere, it can do major damage in cases like where a commit was reverted. And you still get multiple people solving the same conflicts, so even if each person only resolves each conflict once it's still wasteful compared to a merge workflow.
- phanimahesh 3y agogit pull --rebase --autostash