This article describes how to use git rebase -i and git cherry-pick to implement code rollback. Code rollback is a high-risk operation. Use it with caution.

Download the sample source file

Why write such an article? In fact, there is a history: n requirements were developed in parallel in one iteration, and the code for each requirement was gradually merged into the test branch by the time it was tested. Life was very calm, but two days later, the head of the test said, “something happened in our group, the requirements of this iteration cannot be tested within the specified time, but the boss forced the online time, let’s pull out the code with lower priority requirements from the test branch!” . At that time, it was true that 10,000 XXX floated through my heart…

Let’s simulate a scenario where three requirements, Feature1, Feature2, and Feature3, are being developed in parallel in an iteration, all on the same development branch (assuming the test branch is Master).

Feature2 and Feature3 need to modify the same file, so we deliberately created a conflict:

When it’s time to test, feature1’s code is merged into the test branch:

After feature1 fixed a bug, Feature2 will also feature:

Then Feature3 was tested, and when feature3’s code was merged, a conflict that had just been created erupted:

We need to resolve the conflict before merging the code:

After feature3, we fixed a few more bugs:

Of course, Feature2 has been tested but not yet tested, and the bug fixes are for Feature1 and feature3.

At this point, feature2 testing isn’t working properly, and the code needs to be pulled off the test branch…

Just in case, back up the Feature2 branch:

git checkout feature2
git checkout -b feature2-copy
Copy the code

Let’s take a look at the commit history for the Feature2-Copy branch:

git log
Copy the code

We need to roll back the latest 3 submissions (because the development branches of the 3 features are all cut from the time point of the first submission), but in reality there are more than 3 submissions for a requirement. If it’s too much work to revert each commit, why don’t we merge all the commits into one commit and then all revert?

Git rebase -i to merge a commit, you need to concatenate the hashcode rolled back to the commit:

git rebase -i e08ddaf558b9ad84422db5e4b620dcab97623fde
Copy the code

The following dialog box appears:

We need to change the command of the latest 2 submissions to S:

Save the modification and exit to enter the following dialog box:

We need to modify the original commit message:

Save the changes and exit. Look again at the feature2-Copy branch’s commit record:

Three submissions were successfully merged. Congratulations! Next we need to revert the merged commit:

git revert e544464c3de69adef5ca7556001abebaf40b218b
Copy the code

Save and exit, and look again at the commit record for the Feature2-Copy branch:

Naively, I thought merging Feature2-Copy into the test branch would pull off feature2’s code, but it didn’t. The correct way to do this is to use git cherry-pick to merge the Revert commit from the Feature2-Copy branch into the test branch:

git checkout master
git cherry-pick b309f7944d2422d8fe647dca61bda518b192628f
Copy the code

At this point, the code for Feature2 was successfully pulled from the test branch.

Finally, we recommend a Git graphical client: GitUp

Author: Silly love kitten

My garden: sunmengyuan. Making. IO/garden /

My Github: github.com/sunmengyuan

The original link: sunmengyuan. Making. IO/garden / 2017…