During development, we often encounter code rollback situations. Git rollback has two advantages:

  • git revert
  • git reset

When you are developing locally and git has not pushed to a remote end, you can use Git reset to rollback without hesitation. More often than not, we not only push, but also merge master and Merge Other-branch constantly during development to release to pre-release environment tests or multi-requirement merge tests due to long development cycles.

All of a sudden

If A user complains about A, B, and C, the user needs to log out immediately. Only D, E, and F are retained and rolled back quickly to ensure that more users are not affected.

Quarrel with each other? It must be too late. A bunch of people are staring at you from behind, asking if you’re scared…

Next, let’s talk about how to perform Git operations calmly (falsely) in the face of an emergency rollback

Simple scenario

For local operations, use Git Reset to play around. Let’s focus on Git Revert

Roll back “Single commit”

Roll back “Continuous commit”

Roll back a merge

Rollback merge if used directlygit revert mergeCommitIt is actually recursively rolling back each node in it, specified-mIs to specify which branch is the main thread, the current branch is 1, and so on (merge multiple branches > 2, normal 1 and 2)

Advanced scenarios

If all of our problems are like the above, how can we demonstrate the value of a programmer?

Roll back “Mixed Scenario”

As in the following scenario, we expect the regression nodes to contain a merge so that we cannot roll back to place one time. The following methods are available: 1. Roll back D + F and then merge (two operations)

[Recommendation] Using scenario 1, rollback sequentially will handle less conflict. Otherwise, if D and F are a series of commits, rollback costs will be high

Rollback is a bit complicated “Mixed scenario”

In the following scenario, what is special is that I have a feature that rides a bugfix, and I need to roll back the requirement but not the bug

In this case, there are two options:

  • Rollback G, rollback F – step by step through the git lead F ‘E’ – D – C ‘-‘ E ‘(rolling) -d’ roll (not) – C ‘(rolling), the rollback E + D
  • [Recommended] Roll back G, F Discard F ‘, roll back D+E, restore C ‘.. E “is faster and simpler than the first option, without dealing with conflict in the first option
git revert G git revert F -m 1 git revert D.. E git cherry-pick C`` git cherry-pick D`` git cherry-pick E``Copy the code
Copy

Roll back complex “mixed scenarios”

  • Annotation explanation
    • Blue means the tag has been merged into the remote branch Master
    • Red represents the COMMIT that needs to be rolled back
    • Green indicates normal COMMIT
  • Scene interpretationYou start out with a team that gets a requirement that can be split into a custom requirement that can be developed in parallel by two people
    • Two individual Pa and Pb branches are created from the Master
    • Bugfix (v2, V3) was released twice on Master during development
    • Due to the need for continuous testing on pre-delivery, Pa voluntarily merged Master
    • Pb scrapped the old logic and some minor refactoring (stability updates) of the code in its branch B ‘C’ D ‘and has since been developing new functionality & validation locally
    • When it is about to go online, it needs to be verified together with the requirements. After verification, THE Pb releases V3
    • It was followed by a Bugfix release of V4
    • As a result, the product went back on its words.
    • Finally, to scrap the new feature, the product needs to be redesigned, but the old logic is still scrapped as planned.

Roll back the way

In this scenario, rollback schemes are as follows:

  • Go back to the latest remote Master (V4) and manually identify the required code and manually delete it. Deleting your own code is fine, but deleting someone else’s code is a bit more difficult and time-consuming when there is a lot of submission
  • Copy F(v2) to replace Master(V4), manually or by applying B’ -d ‘commit to figure out the situation, copy and paste directly is a convenient method, again B’ -d’ also does not cost much, but manual operation is difficult to avoid errors, especially add/delete files, copy and paste is easy to error
  • Git rollback (O ‘-t’, L ‘, F ‘-k’ ^, B ‘-c’, E ‘-n’) version control is designed to make code management easier. You can also roll back the “rolled back” operation if the rollback is wrong
git revert N`.. S '// Rollback only non-merge Master nodes, leaving the Master code gitlogB``^.. L`` --first-parent --no-merges --pretty=format:%H | xargs | xargs git cherry-pick -n git revert E`.. F`Copy the code
Copy

One last word

Rollback is not a headache, do your homework ahead of time and keep a clear record of commits, otherwise hundreds of commits can become a disaster. Name a few good ways

  1. Keep Commit clear
    • Do one complete thing at a time, do not mix other requirements and bugfixes, do not commit compiled code before completing requirements;
    • Commit is clearly described
  2. Use rebase
    • If there are several commits that do the same thing, rebase them and don’t have a lot of invalid logs init, update, etc
    • After committing code and realizing that a configuration needs to be changed, commit and use rebase to clean up the version tree
  3. Do not merge into a single branch to prevent code cleaning due to changes in live time

If something is wrong, correct it, TKS