svn - 如何理解git的分布式 分支

Question

看了Git官网的这一段介绍更加迷惑了

用 Git 的话，就算你在飞机或者火车上，都可以非常愉快地频繁提交更新， 等到了有网络的时候再上传到远程仓库。同样，在回家的路上，不用连接VPN 你也可以继续工作。换作其他版本控制系统，这么做几乎不可能，抑或非常麻烦。
链接地址》》》

假如

有一个商城项目正在上线，团队中有A、B、C三个程序员，使用git来进行版本控制。总共开发天数是10天，从第1天到第5天，A、B、C都是一起开发，一起提交，一个版本。但是到了第6天开始，C就不提交到远程了，一直都是在自己修改制作。整个项目很多文件，C会把项目中的文件GlobalFunction.php改动很多次，修改了很多函数，也加入了很多自己的函数。随着开发的继续，C还会不断的陆续修改GlobalFunction.php文件。而一直都提交到远程的A和B，也需要经常修改GlobalFunction.php文件，但是A和B会保持同步到Git远程。

合并

到了最后第10天，C可以联网了，然后C提交到远程。可C电脑里面的GlobalFunction.php 跟 Git远程上的 GlobalFunction.php 已经完全不一样了，而且远程的这个文件还经历过了二十多个版本。而C自己电脑里面的也经历过了几十个不同版本。

极大的疑惑

根据git介绍中的那一段的描述，这样的情况下，Git是可以自动合并？如何自动合并？

C已经在GlobalFunction.php中加入了很多函数且期间也经历过了很多次的版本。

---

补充

看到很多介绍Git的文章重点都放在了不需要push到远程，不需要联网就可以使用，真的觉得实在是难以理解。我在sf问也有很多人也在说不用push，/q/1010000000605934#c-1020000000606050-1050000000609657，更让人迷惑。不用push，假如1年或者10年了从来都不push到远程，那么还算是协同工作了吗，git会那么神奇10年之后再联网push过去还可以自动合并

Answer 1

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.

Answer 2

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.

Answer 3

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;

Answer 4

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

Answer 5

The problem you mentioned can only be solved through branches

Answer 6

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.