4 ms·
Any good git "best practices" doc will inform the user to never use rebase on a shared remote repo. The details are given, but sadly I can never really follow t
by sam36 7y ago
Any good git "best practices" doc will inform the user to never use rebase on a shared remote repo. The details are given, but sadly I can never really follow the logic. Rebase always sounds like a good idea (imo). And being the only one to use rebase on my team... I've had several instances where I go to rebase a remote branch onto my local work, and I'm met with tons of conflicts.. except the conflicts are all my own commits from a later time. I've never really figured out why, but I've since just stopped using rebase unless I really know there is nothing funny on the remote branch.
- danzanzini 7y agoThe conflicts from a later time happens because rebase applies one commit at a time. If you solve a conflict from your first commit by applying changes that were made only in the later ones, you'll need to solve this same conflict again and again.
- sixstringtheory 7y agoIf resolving the same conflicts over and over again in many commits gets onerous enough to make it worthwhile investing a little time learning another part of git, you can check out git-rerere (Reuse recorded resolution): https://git-scm.com/docs/git-rerere https://git-scm.com/docs/git-rerere
- sam36 7y agoWhat the heck
- mcv 7y agoRebase should not be done on a large history. Merge long histories, only rebase short ones. Long histories are probably useful to see separately in the git history anyway, and it's only for a history of one or two commits that the extra merge commits begin to dominate the real commits in your history. When in doubt, just merge. It's always safer.