Pushing a scenario to extremes is a bad way to argue.

First of all, what is the purpose of submission? If it is just to synchronize the code to others, then git really has no highlights. Even offline submission can be misunderstood, which is a shortcoming.

I personally think that the purpose of submission is to temporarily store the code (version management to facilitate subsequent rollback of Shenma), the second is to serve as a stage node of the code (this function is completed, submit it), and the third is to synchronize with the server. Share with others.

Git's offline submission can accomplish one or two of the above purposes very well. And because it is submitted offline, you can easily modify the submission record before synchronizing with the server. What is the use of this? For example, I wrote a method and it works, but I want to refactor it, but I am not sure whether it will work properly after refactoring, so I submit a version first so that I can roll it back if the refactoring breaks. After I finish refactoring, I will submit it again. At this point there are two submissions of the same function, and you may only want others to see one submission "XX function completed", so you can easily merge the two submissions. After the final merge, the code repository is very clean. All submission records are submitted because they really need to be submitted. These submissions can be written directly into release notes without "Test XXX" or "Try XXX" appearing. Submissions like that. Based on the same result, you can also submit the code written once in multiple times. For example, if I write three functions, I can choose to submit it three times and finally synchronize it to the server. In SVN, you (write when there is no network The code) can only be submitted once, and then write "Complete three functions A, B, and C". This is not convenient for others to view your code, nor is it conducive to rolling back A, B, and C respectively.

So git’s offline submission brings flexibility. It doesn't mean that with offline submission, I don't need a server, Air will automatically complete the collaborative work for me. This is what I meant when I said at the beginning, "Pushing a scene to the extreme is a bad argument method." Compared with svn, git has more collaborative methods and is more flexible, but it cannot avoid the problem of collaboration. You still need to collaborate and merge codes.

In the process of merging codes, just like SVN, conflicts will also be encountered, so it is still a good habit to synchronize the code with the server in a timely manner when conditions permit. However, since git is a content-based tracking version and svn is a basic file tracking version, git merge is much more reliable than svn. That is, under the same circumstances, git is much less likely to encounter conflicts than svn.

Finally, due to the offline submission feature of git, and the fact that git branches are particularly easy to use, you can also implement local multi-branch management functions, that is, when you are working on a function, you can open a branch locally, then submit it locally, and do After it is finished, merge it and push it to the server. For others, this branch does not exist, but for you, you can switch working status at any time (write new features or switch back to correct bugs). SVN can also cut branches, but its branches cannot only exist locally. If branch collaboration is adopted, there will be a lot of branches, some of which others do not need to care about. What's even more troublesome is that if you are halfway through writing a new feature and need to go back and correct bugs, you can only submit the unfinished code to the svn server. In my personal opinion (submit the unfinished code to the repository server) This is a very bad behavior, but with git, because the branch is offline, after I submit it, I switch back to fix the bug, then switch back again, and after the function is completed, I merge the submission records and everything is perfect.

If both parties change different files, or different parts of the same file, git can automatically merge them.

If the same part of the same file is modified, git cannot automatically merge. This situation is called a "conflict". Git will list the latest versions of both parties, and then the person who performed the merge (C in the example) ), edit manually.

In actual development, if two people just add functions to this file, they can be merged automatically. The conflict mainly occurs when the same line is modified.

Answer to supplement:

Many introductions emphasize that git can commit offline, which is intended to compare with svn. In svn, only the server has a complete repository, and the client's code history is not complete. Each client in git is a complete repository, and push and pull operations are actually synchronization between multiple complete repositories.

The advantage is that you are not afraid of the server hanging up or being lost. Everyone has a complete version library. This is also the starting point for Linus to develop git (Linux is an open source project for multi-person distributed collaboration). The disadvantage is that permission management is relatively poor. , everyone has a complete repository, which may lead to the code (all modifications in history) being accidentally leaked.

Finally I have a question that I can answer well;

First let’s talk about the hypothesis of the question:

C I stopped interacting with the remote from the 6th day and started playing by myself. What are you doing? This is not distributed. Distributed means when the network is available. Distributed does not mean that it does not synchronize with the remote after a few days;

Since the file is called GlobalFunction.php，那么这个文件就是修改极少的（或者说修改相同的一行是很少的），类似于 Python 下的 setup.py，有时只是到了新版本发布的时候你才会修改一下 version variable;

My personal understanding of GIT’s branch concept is that it allows for faster collaborative development based on one or some branches, such as a warehouse foo 有一个 分支叫做：master ，那么 A，B，C 进行协同开发的时候会在本地基于这个共同的分支 master 进行本地分支，比如 A 的本地分支叫 a-dev，B 的叫：b-dev，C 的叫 c-devHow did it come about?

git checkout -b xxx origin/master # xxx 代表 `a-dev` 等

Secondly, let’s talk about the merger mentioned by the questioner:

If C is locally based on the master 进行了本地分支 c-dev 那么 C 一直可以更新本地 master 分支而不影响本地分支 c-dev（而此时你可以一直在 c-dev branch):

git pull origin master:master

What about local master 更新了，怎么反应在 c-dev? It's simple, GIT has already thought of it for you:

git rebase master # 此时你在 `c-dev` 分支

After going through the above, there are only two situations that may occur: 1. Merge conflicts occur, rebase 失败；2. 无冲突（可能会自动 merge），本地 master 最新状况跟本地 c-dev merge;

For the occurrence of 1, GIT will not automatically resolve conflicts, but it can try to automatically merge (merge). If it fails, it is called a conflict; conflicts generally refer to different submissions that modify the same line (several lines) of the same file. ) content, developers need to resolve conflicts themselves;

Personal summary

Branch is the killer feature of GIT that distinguishes it from other centralized version control systems (killer feature）；rebase is the killer feature of GIT branch; GIT’s distributed features are inseparable from GIT’s good branch features;

When a conflict occurs, SVN compares line by line, while Git records operations, such as adding a line, deleting a line, or modifying a line, so the merge process is easier

The problem you mentioned can only be solved through branches

Simply put, it may be possible to merge automatically, or it may not be possible.
Each commit in Git saves a diff. You can just git show a commit and take a look. The diff will try to match several lines before and after the original modified line. If it can match, the diff can be automatically merged.
For example, if C's patch modifies a value in the fifth line, it is not committed. A and B have been adding new functions to GlobalFunction.php. These functions are added at the end of the file. Then when C is merging, Git can complete the merging through cherry-pick.
If both parties have modified the same place, the conflict will have to be resolved manually.