Resolve git upload conflicts

In the following cases, in order to make the content of the presentation more concise, we will not write very canonical submission comments according to the above specifications, and use the -m options to do so git commit . Listen to us, but don't learn to do ^ ^.

Conflicts occur in different files

The simplest private project you have encountered may be configured with only two or three developers. The "private project" here means that the closed source will not be published externally, but you and other developers can access the code base.
In this context, you can track a project flow as you would with subversion or other code control systems. You can still use features such as offline uploads, branching, merging, and the process is very similar. The main difference is that the merge operation can only require a client, without having to immediately synchronize to the service segment. Let's take a look at what it would look like when two developers started working together to develop the code base. John was one of the developers who cloned the code base, made some changes, and then uploaded the changes locally. (In this case, we will ... Replaces the occurrence of large segments of the protocol information to simplify the case)

# John‘s Machinein /home/john/simplegit/.git/...‘removed invalid default value‘111 deletions(-)

Another developer, Jessica, did the same thing, cloned the project and submitted his own modifications to the Local:

# Jessica‘s Machinein /home/jessica/simplegit/.git/...‘add reset task‘110 deletions(-)

Now Jessica sync her changes to the server:

# Jessica‘s Machine$ git push origin master...To [email protected]:simplegit.git   1edee6b..fbff5bc  master -> master

John also intends to synchronize his modifications to the server:

# John‘s Machine$ git push origin masterTo [email protected]:simplegit.git ! [rejected]        master -> master (non-fast forward)errortoto‘[email protected]:simplegit.git‘

John failed to sync his changes to the server, because Jessica was doing the same thing at the same time. This is especially important for you who have used subversion, because you may notice that the two developer changes do not involve the same files. In this case, subversion will automatically complete the merge, but git will not, so you need to change the local merge two people first. John had to get Jessica's modifications, merge the changes, and then synchronize with the server.

$ git fetch origin...From [email protected]:simplegit + 049d078...fbff5bc master     -> origin/master

At this point, John's local repository is almost like this:

John ' s Divergent history

John knew that Jessica's changes were irrelevant to his own, but he had to merge the changes into his local library before the server allowed him to synchronize his changes:

merge origin/masterMerge made by recursive. TODO |    1 + 1 files changed, 1 insertions(+), 0 deletions(-)

The merge action is complete, and John's upload record is now like this:

John ' s repository after merging Origin/master.

Now John can test his code to make sure they're still working, and he can sync his changes to the server:

$ git push origin master...To [email protected]:simplegit.git   fbff5bc..72bbc59  master -> master

In the end, John's submission record looks like this:

John ' s history after pushing to the origin server.

Conflict occurs involving the same file

At the same time, Jessica is developing a topic branch. She created a branch called ISSUE54, and then submitted three modifications on that branch. She has not yet obtained John's amendment, and now his submission record is this:

Jessica ' s topic branch.

Jessica to synchronize John's changes:

# Jessica‘s Machine$ git fetch origin...From [email protected]:simplegit   fbff5bc..72bbc59  master     -> origin/master

Jessica pulled the modifications that John synced to the server, and now Jessica commits the record:

Jessica ' s history after fetching John ' s changes.

Jessica thinks her branch is ready, but she wants to know what she has to merge before she can sync her changes to the server. She runs git log to see the following:

--no-merges issue54..origin/mastercommit 738ee872852dfaa9d6634e0dea7a324040193016Author: John Smith <[email protected]>Date:   Fri May 29 16:01:27 2009 -0700   removed invalid default value

"Issue54. Origin/master "The syntax of this parameter is a log filter that can require Git to show only the list of commits that are on the second parameter branch Origin/master, but not yet on the Issue54 branch. See "Commits Ranges" for more information on this parameter syntax.
Now, we see from the output that Jessica's uncommitted John commits only one. If Jessica is to integrate Origin/master, this commit will modify her local content. Now Jessica to merge her subject branch into the main branch, merge John's commit to her main branch, and finally sync to the server. First, Jessica back to her main branch to integrate all these changes:

to‘master‘is‘origin/master‘by2and can be fast-forwarded.

Jessica can merge Origin/master first, or you can merge issue54 branches first, they all need to be uploaded, so the order is not important. The final project status snapshot should be the same, regardless of the order, only upload records will be a little different. Jessica Select Merge Issue54 branch First:

$ git merge issue54Updating fbff5bc..4af4298Fast forward README           |    1 +|    6 +++++-261 deletions(-)

Merge succeeded. As you can see, this is a very simple and fast push, and now Jessica to start with John's modifications (that is, the contents of the Origin/master Trunk branch):

$ git merge origin/masterAutolibbylib/simplegit.rb |    2111 deletions(-)

All things are very clean merge, now Jessica look at the upload record like this:

Jessica ' s history after merging John ' s changes

Jessica's Master branch is accessible to origin/master, so she can successfully sync to the server (assuming John hasn't uploaded any other changes during this time):

$ git push origin master...To [email protected]:simplegit.git   72bbc59..8059c15  master -> master

Each developer submits his or her own changes and has successfully merged with others.

Jessica ' s history after pushing all changes back to the server

This is one of the simplest workflow instances. After you develop a period of time, usually refers to the development of a topic branch, to integrate this time to complete the changes to your Master branch to submit. When are you going to share? Your changes, you put the changes into your Master branch, get Origin/master and close, and finally sync to the server. This process sequence is similar to the following diagram:

General sequence of events for a simple multiple-developer Git workflow.

A bit more content, translation is not detailed, follow-up continuous improvement.

Original link

Resolve git upload conflicts