Closed michaelachrisco closed 5 months ago
Github now has some excellent docs here that go over such an instance: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/about-merge-conflicts They have multiple ways of dealing with git merge resolutions include using GH and using the command line.
We did a talk on this subject: https://docs.google.com/presentation/d/1dqeEkDZx8X5l7GJgiDfenXsmi-0yxou4EFRoea5BXcM/edit#slide=id.g1f87997393_0_782
Any team going through the same issue, feel free to steal!
Is your feature request related to a problem? Please describe.
From @mwallert
Describe the solution you'd like.
The below is what I think should be the standard around the shop:
rebase
if possible (unless they are really confident in their skills).If we are developing a standard, then I would also recommend keeping a straight copy of the git repo BEFORE they applied any of the above. I have had instances where history disappears when developers start playing around with
rebase
. Not a huge deal if you know what you are doing, but that is what the branch protections are supposed to be protecting you from.Describe alternatives you've considered
git cherry-pick
is a viable alternative. I used to cherry-pick for the same kind of operations and then apply both commits to the branches in question. The only benefit is you don't lose the history of the branches. The problem is that doing it correctly takes some time and may result in a gnarly git tree.Additional context
https://github.com/Shift3/terraform-modules/pull/34
New Docs should probably go here: standards/git-commands.md