search

Shift3 / standards-and-practices

Standards and Practices for Bitwise Industries
https://shift3.github.io/standards-and-practices/
63 stars 41 forks source link

[Feat]: Specify How to deal with git merge/history errors #319

Closed michaelachrisco closed 5 months ago

michaelachrisco commented 2 years ago

Is your feature request related to a problem? Please describe.

From @mwallert 

We have a merge conflict on develop because of a hotfix applied to main. This is uncommon and I have a flow I normally use to fix this issue but I wanted to run it by you for standards sake. Normally this would follow the same as a feature branch where we run a rebase on develop to main git rebase origin/main , and then we force push to develop after resolving the conflicts. All of this would be seen via the PR and so we don’t have any hidden code getting into develop or main. In order to do this I would normally remove the branch protections for develop for this push, and reinstate them after. Thoughts?
This flow would also only occur when we have hotfixed main and there is a merge conflict when merging develop into main

Describe the solution you'd like.

The below is what I think should be the standard around the shop:

  1. Developers should try to resolve conflicts without rebase if possible (unless they are really confident in their skills).
  2. Team leads should be the only ones that can temporarily remove branch protections for force push, fixing merge conflicts that cant be resolved in editors, etc...).
  3. Branch protections MUST be turned back on as soon as the operation is completed.
  4. I think the team lead may want to record that they did so, since they just messed with the git history.

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

michaelachrisco commented 2 years ago

Related to: https://github.com/Shift3/standards-and-practices/issues/56

michaelachrisco commented 2 years ago

Related as well: https://stackoverflow.com/questions/10761348/git-merging-hotfix-to-multiple-branches

michaelachrisco commented 1 year 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.

michaelachrisco commented 1 year ago

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!