Record a git amend accident handling solution, gitamend

Record a git amend accident handling solution, gitamend
I. Problem Review

The problem is caused by git commit -- amend. A commit has been pushed to the remote develop, but then amend is performed on this commit, resulting in a change in the commit hash code. In addition, N commit operations are performed after this commit.

<Begin>

I drew a brief picture about the situation ,. The following green is the last place of the same, and the red one makes the same functional message, but after the develop is completed, it changes a lot and uses amend to squeeze it.

This is a headache, because there are too many changes in the amend commit. I am using methods that can avoid conflicts, but will change the commit tree of develop.

Git checkout developgit reset 2c4532 // above 97,98, 99 changes will be made out of git stash // first save these changes to git reset -- hard 5d67bc // and so on, so 96 is completely removed, the Code returns to the 95 state. git cherry-pick 8a6f7f // paste the modified feature commit (96 feature, in this step, 100% won't conflict with git stash pop // release the changes previously stored. This step cannot ensure that 100% won't conflict with each other, but actually because the two functional modules are relatively different, so there is no conflict. Git add. git commit-m "" // compress the 97,98 and 99 commit above develop into one and commitgit cherry-pick 86f6cc d34c7 2817f5 // In this step, the feature Branch's 97,98, 99 commit is pasted, because these three are basically developed based on 8a6f7f, so there is no conflict. Dong borran blog Park

<End>

In this way, the commit tree of develop is shown in (97th is the one that compresses the previous, 98, and 99), which can be compiled and implemented through functions. However, the disadvantage is that develop needs to be pushed up at this time.

 

The solution proposed by another person in the group is

<Begin>)

Git checkout feature // The operation is performed on the feature branch. The develop code git reset 5d67bc // The "unscientific" commit 96,97 on the feature branch, and 99 are all put out git stash // All temporarily saved git rebase develop // hurry up, new code 100% integrated with all develop does not conflict. git stash pop // release the four commit codes that were previously rubbed together. There will be a lot of conflicts at this time. Git add. git commit-m "fix" // after the conflict is resolved, commit it. // then, add the last commit merge to the develop. In the final result, develop is as follows:

<End>

We can see that this method does not need to force the code to push develop. Theoretically more scientific, but a large number of conflicts need to be resolved in the middle.

Afterwards, I thought that the two methods have their own advantages and disadvantages. If there are not many Members in the group, I can perform the forced development operation under the supervision of everyone. If a large number of conflicts are solved, the error may be more likely to occur if-f pushes develop more easily after the differences are clearly understood. Of course, if it is a large project, dozens of teams, and the remote end is bound to the compilation check, and the project of the merge rule can only use the second method.

 

2. Other experience

For a code farmer, what's worse than writing a bug is losing or messing up the code. There is also a unified solution to this problem.

①. Git reset -- hard hash code, which is very common. If something goes wrong, return directly to a secure commit.

②. Git reflog won't be able to use the first command for operations such as rebase or merge, because the contaminated command is not just the last commit. In this case, use this universal recovery command to return to the hash code of an operation.

③. But the first two methods are to restore some code that has already been added to git. If some code has not been commit yet, those commands will not be able to help you if you lose them. At this time, you can only check whether the IDE has local history. (Local history is equivalent to implementing a git-like function by IDE.) There was a 3rd-case experience before. At that time, I gave the code without commit to the reset and used localhistory for restoration. Fortunately, both iOS xcode and Android Studio have local history,

• The local history of Xcode is in the navigation bar → View → Version Editor → show Version Editor
• The local history of Android Studio is in the file directory on the left → select the root directory → show local history

 

If there is a better solution to the problem mentioned above, you are welcome to discuss it together.