Git how gracefully fallback Code

Foreword

From the start programming started using Git code management, first own play Github, and use Gitlab at work, although quite a long time, but only some common operations, such as push-pull codes, submit, merger or other, more complex operations not used, read the tutorial gradually forgotten, and some sorry Linus great God.

Out to mix always has, the other day he would face in a very Git Zaoxin the scene, and was not previously in-depth understanding of Git commands and paid the price of an afternoon.

First introduce such a scenario, we project a jar package introduced another project when the N version rose A version from which they gradually released B, C version, but after the C version suddenly found a jar package A version introduced there are significant performance issues, B, C versions are based on the a version is released, the jar package to fix performance problems, such as recurrent jar package version will have a few days, there may be online at this time of emergency to repair Bug, so it caught in a dilemma.

A final decision before the first version of the code to fall back, then Bug fix based on the old version, it began the road to suffering of five hours.

Free to reprint, the article will continue to revise, please indicate the source address: https://zhenbianshu.github.io .

Tentative basis

revert

First, be sure that revert, git revert commit_id to produce a complete opposite of submission and commit_id, namely commit_id in to add, revert commits is removed.

But after using git log to view the records submitted, I gave up the idea, because too many times to submit, as well as a few from the middle of the other branches merge operations. "Interest in" we do not submit a clean record, to complete the revert from version C to N version, I need to perform revert reverse operation dozens of times, if the order in which the wrong time, the final result may be wrong.

In addition, we know that when we are making the code merge, the merge will generate a new information submitted, and the need to specify the parameters m revert the merge commit, to specify mainlinethat the mainline is the main line, but also we want to keep the main branch code, submitted from the feature branch to develop the branch consolidation, or merger of branches to develop master's okay determined, but feature branches merge into one another, which I know which is the main line ah.

So revert copywriter was abandoned.

Reset

Then consider reset the, also can reset the code back to a particular submission, but the difference is with the revert, HEAD pointer reset is submitted refers to a particular submission, submission records will disappear after, like they never had such a submit.

But since we have been given tips on feature development branch, I fall back after a commit, will be merged into the branch feature will develop when the branch code. This is because the feature branch back to back after submitting, in git's workflow in, feature branch is behind the develop branch, and merge, they need and develop the branch kept up to date sync to develop branch need to be merged develop branch data to feature on the branch, and the combined, the original code is reset back.

This time the other option is to perform reset on the master branch, use the --hard option to completely abandon the old code, reset and then forcibly pushed to the far end.

 
  master> git reset --hard commit_id
master> git push --force origin master

But there are still problems, first of all, our master branch in gitlab where is protected, you can not use force push, after all, is big risk, in case it was reset and then forced to submit to push it, although you can use the beginning of the reflog recovery, but also toss.

In addition, reset after all too brutal, we still want to retain your history can also troubleshoot problems later reference.

Upgrade fusion

vulpine

We had to use a search engine to continue the search, you can see it was suggested to use rebase multiple submit merged into one submission, and then use revert to produce an anti-submitted idea of this method is very clear, and revert to rebase command with two well , equivalent to using revert rollback an upgraded version.

Let me talk about rebase, rebase is "rebase" means, where the "base", we mean that in git workflow [repeatedly] commit formation, use rebase, we can change these historical submit, modify commit information, combining the plurality commit.

The document describes the rebase There are many steps we use it directly for the code to be rolled back.

First, cut out a new branch F, use git log inquiries about 要回退到the commit version N.
Using a command git rebase -i N, -i pattern after specific interaction opens git rebase editing interface, the form:
```
 pick 6fa5869 commit1
 pick 0b84ee7 commit2
 pick 986c6c8 commit3
 pick 91a0dcc commit4
```
These commit from the old to the new arrangement from top to bottom, we just need to add an action command before commit_id can, in merger commit this demand, we can choose pick(p) the oldest commit1, then added before subsequent commit_id squash(s) command, these commits are merged into the oldest commit1.
After saving rebase the results, and then edit the commit message, so that this rebase failure, before git commit these will be deleted, and change it into one new commit5, if wrong, it can also be used git rebase --abort/--continue/--edit-todo to revoke the previous editor and continue editing.
This time, submit records on the main branch is older, commit1, commit2, commit3, commit4, and submit records on the F branch is older, commit5due to the branch F ancestor node is older, significantly behind commit4 main branch, the branch will be merged into the main branch F is not allowed, so we need to implement git merge master the main branch to merge F branch, git will find the combined content commit1 to commit4 submitted and modify the contents of commit5 branch F are identical, it will automatically merge the contents of the same, but more than a commit5.
Commit5 once again revert to the anti-F filed on branch, on the realization of the submission commit1 commit4 all back.

Tricks of this approach is that the clever use of submitted historical operating functions rebase git and automatically modify the same identifying combined characteristics, although the operation complicated, but still have retained full submission history.

This modification work history rebase submitted very practical, can solve a small feature we encountered submitted several times to do so, but the git history mess of problems, just avoid the development at the same time in multiplayer branches use on the line.

Unfortunately, that day I do not understand this idea to rebase, and because tried several methods will not panic too, after the rebase is completed, the merger was rejected after the main branch had doubts about the feasibility of these methods , coupled with a colleague asked sounds more feasible way to interrupt the operation.

File Operations

This more feasible way is to file operation, then let git to identify changes, specifically:

The main branch cut from a same branch with the main branch F.
Copied from the Document Management System project folder bak, bak used within git checkout N the code is cut to the desired submission history and restore files within this time will git bak to N status.
From within the document management system, the bak folder 除了 .git all the contents of the folder to copy and paste under the original project directory. Pure git will recognize from the file level to change, and then update the work area.
Performed in the original project directory add 和 commit, complete counter-submission.

The trick of this approach is to use the identification of the document git itself, does not involve the operation of the workflow.

summary

And finally against file-based operations successfully completed the code rollback, hindsight is really a sad tears.

To get my five hours not in vain, re-set about the scene at the time, to learn and summarize four kinds of tag rewind way:

revert need for fallback submit much history, and no merge conflict scenarios.
If you can strong push code to master, git log in and wanted to be rolled back the code marks no longer appear, you can use the git reset --hard + git push --force method.
If you have some geek, the pursuit of a "regular and orthodox" way back the code back and forth, rebase + revert to meet your needs.
If you do not care whether elegant, want to use the simplest, most direct way, the file operation is appropriate.

git is really fast hardware code management tool, start with simple three five commands in combination is sufficient to complete the work needs, but also for geeker they were very friendly, and you want to show its support operations, life-long learning ah.