git revert and this hole?

Recently also has finally opened the code to write the journey, I can only silently say a sentence, writes the code the feeling, simply cannot again cool!

But also because Git branch manages the egg ache to be very long, therefore must record and share with everybody this time the pit father's travel.

Write in front

Each company has its own GIT branch management specification, which is especially important when there are more developers in the project team. So we have to master Git's branch management. The basic routine is to have a main line, and then in the iteration cycle, each developer pulls their own branch, until the completion of the development of the merge back to the main line, release version.

Flow chart

Specific GIT Code branch management look at this. Good: nvie.com/posts/a-successful-git-branching-model/

What's going on?

How on Earth was the Git version rolled back to the pit? No hurry, wait for me to slowly.

In Plump's project team, when a new requirements review is completed and the development status is entered, people will pull their own branches based on the develop branch, named Feature/xxx, and then develop each on their own branch.

Due to the different development of business, so in the development of the requirements, the integration of code, the general will not appear in conflict situations, even if it appears, it should be easier to solve.

A strange problem can be seen in the recent merge.

：

1.png

My current branch is Feature8.29.0_nanchen, which has been merge with the latest code on the release8.28.0 branch, without any commits locally. For some reason now, I need to merge the Feature8.28_buygifts branch code developed by another colleague into my branch. for development.

A lot of conflicts happened unexpectedly.

2.png

Let's use it to git status see what's going on.

3.png

As you can see, git thinks that our current branch deletes a lot of files that exist on the feature8.28_buyGifts branch.

We vim to view the file situation. Here is the first Marketitemsinfo.java to do.

4.png

After we looked at the other conflicting files, we found that all were related to this class, and that the Presents files were actually feature8.28_buyGifts developed by the small partners of the development Branch, and the main branch could not intervene, and it was confusing.

To verify our own conjecture, we look at Marketitemsinfo.java's submission history.

5.png

As we thought, no one has ever moved this file in 7 months.

So a document that has not been moved by people for 7 months, how can the merge of the time of the emergence of this puzzling conflict?

Take a look at all the logs for the current branch.

6.png

Seems to have found a bit of an anomaly. The small partner once went to release8.28.0 for the merge operation, and was told that no test can not be merge to the main line, he also release8.28.0 branch did revert operation. So it might make git think that release8.28.0 has such a file modification, because after the operation is revert, so git lg <fileName> when used, also can not see the recent changes to the file record.

I can only say that this may be the reason, if you have the opinion of the message guidance.

If so, then we just need to do the merge Feature8.28_buygifts branch code before this revert operation, it should be no problem.

In order to verify, we re-establish a branch and then reset to the revert operation before the merge to see if such a situation still occurs.

7.png

There is clearly no task conflict.

Let's try again and merge after the revert.

8.png

As we thought, when we reset to the revert submission, then the merge directly occurred this conflict.

That, in a sense, has confirmed our ideas. Git does take this file as a modification.

What's the deal?

Encountered such a problem, intuitively, is certainly the change of the conflict, all with the small partner's code, as the main line of code, has been confirmed that no one moved these files.

The worst way to do this may be to simply discard the small partner's operation and then forcibly write the code behind him again (because the amount of code behind him is very small).

Why does this revert operation occur?

In the final analysis, this is the revert of the disaster.

I asked the small partner, I learned that he was in the release8.28.0 Main branch of the merge his own code, and push to the server, was told that the non-measured code can not merge into the main branch, want to abandon the push to the server of the merge operation, so the use of RE The vert command.

The correct operation?

I write this correct operation problem, is really afraid to write. But dare to write a bit. If I want to abandon myself push to the server commit, I will definitely choose reset after the push operation.

1. First Use Git Reset-hard < version number > Let HEAD pointer point to the commit ID before merge. (Note that this is directly discarded after all commits, using--hard, here because there is no other code to submit)
2. Then use the GIT push Origin < branch name >-force command to force the commit push to the server.

Written in the last

In fact, I myself to Git's operation is also somewhat ambiguous, but still hoped that can use this lesson to give everybody the simple communication.