The original address: http://blog.23lab.com/2017/11/14/find-missing-code-in-git/

background

Mass team in A few years ago to git, local library and branch of git features make the code management more convenience, but also because of the local library and branch of mass use led to frequent the merge between code, we have met the git team before after the merge code, is A certain change development presented, After a sequence of commit, merge, and push changes, some changes are lost. If you look at the commit history, there is no corresponding change record. After each commit comparison, one merge is always found, but there is no way to explain why the merge is lost. Finally, in order to ensure that all the lost code is retrieved, a full comparison of Beyond Compare is usually selected, which is a painful and sleepless solution.

Today I met this problem again, and this time it was even more weird. When I was checking why I lost it, another colleague submitted the code and the lost code came back. At that time, I could only think of one word, that is: damn it. However, if you keep your cool and think about it, the probability of losing code in Git is very small. It must be our posture is wrong. Git pull = git fetch + git merge git pull = git fetch + git merge

The validation process

In order to verify this problem, I built a new Git library to duplicate the above problem. According to the simulation we encountered, I used three users to simulate cross-submission and merge, namely user1, user2 and user3. For convenience, I did not choose to register three users, but added their names in the submission information. Two code conflicts can be created, and both are partially committed. The final code submission record is as follows:


In order to get a clearer view of the process, I split the three user submissions and made the following diagram according to their order.


How did you lose the code?

First, in steps 1 and 2, user1 and user2 make local changes to file1, respectively. Only User2 also makes changes to file2, so if they merge, you can expect file1 to collide and file2 to not. After user2 has made a Git push, the head of the git remote library should point to user2’s last commit. Then user1 does git pull, because file1 has been modified by two users and needs to be merged, and user1 handles the conflict and commits only file1, but not file2 (you need to reset manually on the command line, but you can choose to commit only file1 with some GUI tools). At this point, the library has been lost. User2 :file2:add line change, this is the beginning of the carnage, lost code. You can compare before and after merge.

How does the code “recover”?

I just verified how the code was lost, but the matter is not over. I mentioned above that the weirder thing is that the code is restored. What’s going on here? User1 commits twice after completing the code in step 3, modifying file3 and file1, while User3 joins and changes file1 locally (expected to conflict with user1), then user1git push, then user3 git pull, A file1 conflict is reported, and user3 commits a similar error to user1 by submitting only the conflicting file file1. If you click step 3 to lose the code, the changes to File3 are definitely gone, but if you look at the changes to File2, it is back, so the so-called recovery is not recovery, the so-called loss is not lost, I ask you are afraid. Even scarier is the change history of File2.


There is no record of any change in the process of vanishing and recovering, which is where we often find it difficult to trace down. It appears that the first error ignores the change to this row, while the second error can be interpreted as ignoring the change to which this row was added, but none of these are recorded.

conclusion

Git merge: Commit 100 files to git merge: Commit 100 files to Git merge A cautious new student may choose to submit only his or her own changes, but he or she is making a big mistake. In addition to this situation, some new students will modify git default merge information. This is also a very bad habit, and it is not easy to see what is merge when checking problems. So please note:

  • Git merge: Do not commit partially!

  • Git merge: Do not commit partially!

  • Git merge: Do not commit partially!

  • Git merge information do not change manually!

  • Git merge information do not change manually!

  • Git merge information do not change manually!

If you feel that you have gained something after reading it, please click “like”, “follow” and add the official account “Ingenuity Zero” to check out more wonderful history!!