“This is the third day of my participation in the First Challenge 2022. For details: First Challenge 2022”

A GIthub PR submission will show all commit problem solutions

The cause of

Recently, while committing code to the open source repository in my free time, I noticed that the commit I had previously committed and merged into upstream was still there. The specific phenomenon is shown as follows: The first PR

The second PR

The third time in PR

.

Although this has no impact on the submission effect, it does affect our mood when we submit and check the state of the submission record. So I decided to take a look and see how to solve the problem.

Looking for a reason

So I looked it up on the Internet to see if anyone had the same problem, and there were quite a few. Of course, there are many good brothers who have written a lot of solutions to the problem, but have not found a good solution repeatedly. What to do? Well, run through all the submitted procedures yourself and analyze the results to see if you can find a better solution. I remember when I first signed up for Github, the first library I used was to learn how to commit using Git. Well, it seems a good time to use it again. I also established a lessismore-ing organization. So I could have lessismore-ing fork my own Learngit repository and then simulate PR to open source. I then ran the following test.

  1. There’s only one testcommitthenPRIn the case

inforkUnder the warehouse, add a file, then submit the upload, and finally proceedPR, the process is as follows.forkThe warehouse submits the code and thenPR, see below

upstreamThe warehouse carries out MR, as shown below.

The commit record for the upstream repository is increased by two, one for fork repository 84AEDF and one for MR operation 99f017d

This is exactly as expected.

  1. There’s only one testcommitthenPRIn the case

inforkTwo are built under the warehousecommitthenPROperation, the process is as follows. Fork the repository commits twicecommitAnd thenPR

upstreamAt this time, the warehouse will give us three options respectively asCreate a merge commit , Squash and merge,Rebase and mergeLet’s do it one by one,

Create a merge COMMIT, Create a normal MR, and keep all the commits.

And then lookupstreamWarehouse commit records, and no1The steps are recorded similarly as follows.

At this point, when we PR again, there is no commit showing that MR has been committed.

  1. We continue and repeat the steps again2This time we先生In the manner ofSquash and merge.

Skip the COMMIT and PR process and look directly at MR.

And then lookupstreamCommit records for the warehouse

Compared with the commit record, there is only one more MR message. Our commit records have been erased.

At this point, when we PR again, we will see the commit that has been committed. Well, this seems to be the reason for the double commit situation. In order to be rigorous, we continued to experiment with the third MR case, but at this point there was already a conflict and Rebase and merge could not be performed.

To continue with the Rebase and merge experiment, we Rebase on the fork branch to resolve the conflict and commit the code (this step is omitted because it is unnecessary compared to the experiment process).

  1. We continue and repeat the steps again2This time we先生In the manner ofRebase and merge.

Skip the COMMIT and PR process and look directly at MR

And then lookupstreamCommit records for the warehouse

We can find that after MR, there is no MR information, only the commit information we submitted.

After the above four steps, we can determine that the reason why the PR submitted to Github will display the COMMIT that has been MR is that upstream warehouse adopts squash and merge during MR, so the commit information of author is erased

How to solve

Method 1: Rebase

# in your local master

# rebase, if there is a conflict, resolve it
git rebase upstream/master

# --force is rejected because there is a disagreement with the remote branch
git push origin master --force

Copy the code

Other methods

Since other methods I have looked up on the Internet and tested on my real machine do not completely solve the problem of the fork warehouse showing a COMMIT when PR to upstream, I will not write it here. If a partner has other ways to also can leave a message interaction.

Afterword.

When contributing code to an open source repository, it is necessary to learn how to deal with these issues because many warehouse managers prefer squash and merge for the sake of overall branching consistency and consistency. At the same time, we must try our best to deal with the information of commit when proposing PR, so as to ensure the smoothness of merge. Hope this article can help you, Bye.

Refer to the open source address in this article

my learngit

lessIsMore-ing learngit