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

시나리오를 극단적으로 밀어붙이는 것은 나쁜 논쟁 방법입니다.

우선 제출의 목적이 무엇입니까? 단순히 코드를 다른 사람과 동기화하는 것이라면 git에는 실제로 하이라이트가 없습니다. 오프라인 제출도 오해를 받을 수 있다는 점입니다.

개인적으로 제출의 목적은 코드를 임시로 저장하는 것(Shenma의 후속 롤백을 용이하게 하기 위한 버전 관리)이라고 생각하고, 두 번째는 코드의 단계 노드 역할을 하는 것(이 기능이 완료되면 제출), 세 번째는 이를 서버 동기화에 제출하고 다른 사람들과 공유하는 것입니다.

Git의 오프라인 제출은 위의 목적 중 한두 가지를 매우 효과적으로 달성할 수 있습니다. 그리고 오프라인으로 제출하기 때문에 서버와 동기화하기 전에 제출 기록을 쉽게 수정할 수 있습니다. 예를 들어 메소드를 작성했는데 작동하는데 리팩토링을 하고 싶은데 리팩토링 후에 제대로 작동할지 확신이 없어서 리팩토링이 깨지면 롤백할 수 있도록 먼저 버전을 제출합니다. 리팩토링 완료 후 다시 제출하겠습니다. 이 시점에서 동일한 기능에 대한 두 개의 제출이 있으며 다른 사람에게 "XX 기능 완료"라는 제출 하나만 표시되도록 하여 두 제출을 쉽게 병합할 수 있습니다. 최종 병합 후 코드 저장소는 매우 깨끗합니다. 제출해야 하는 모든 제출 기록이 "Test XXX" 또는 "Try XXX"와 같은 제출 없이 릴리스 노트에 직접 작성될 수 있습니다. 동일한 결과를 바탕으로 한 번 작성한 코드를 여러 번 제출할 수도 있습니다. 예를 들어 함수를 세 개 작성하면 세 번 제출하고 최종적으로 서버에 동기화할 수 있습니다. 네트워크 없음 코드)는 한 번만 제출할 수 있으며 "A, B, C 세 가지 기능 완료"라고 작성하면 다른 사람이 코드를 보는 것이 편리하지 않으며 A, B, 롤백하는 데 도움이 되지 않습니다. 그리고 C.

그래서 Git의 오프라인 제출은 유연성을 제공합니다. 오프라인 제출 시 서버가 필요하지 않으며 Air가 자동으로 공동 작업을 완료한다는 의미는 아닙니다. 제가 처음에 "장면을 극단적으로 밀어붙이는 것은 나쁜 논쟁 방법이다"라고 말한 것이 바로 이것이다. svn에 비해 git은 더 많은 협업 방법을 갖고 있고 더 유연하지만 여전히 협업하고 코드를 병합해야 하는 문제를 피할 수는 없습니다.

코드를 병합하는 과정에서 SVN과 마찬가지로 충돌도 발생하므로 조건이 허락한다면 적시에 코드를 서버와 동기화하는 것이 좋습니다. 그러나 git은 콘텐츠 기반 추적 버전이고 svn은 기본 파일 추적 버전이므로 git merge는 svn보다 훨씬 안정적입니다. 즉, 동일한 상황에서 git은 svn보다 충돌이 발생할 가능성이 훨씬 적습니다.

마지막으로 git의 오프라인 제출 기능과 git 브랜치가 특히 사용하기 쉽다는 사실로 인해 로컬 다중 브랜치 관리 기능을 구현할 수도 있습니다. 로컬에서 분기를 열고 로컬로 제출한 다음 병합하여 서버에 푸시합니다. 다른 사용자에게는 이 분기가 존재하지 않지만 언제든지 작업 상태를 전환할 수 있습니다(새 기능을 작성하거나 다시 전환). 버그를 수정하기 위해). SVN은 분기를 잘라낼 수도 있지만 분기가 로컬에만 존재할 수는 없습니다. 분기 협업을 채택하면 다른 분기가 신경 쓸 필요가 없는 분기가 많아지게 됩니다. 더 문제가 되는 점은 새로운 기능을 절반쯤 작성했는데 돌아가서 버그를 수정해야 하는 경우 미완성 코드만 svn 서버에 제출하면 된다는 점입니다. 제 개인적인 의견으로는 (미완성 코드를 리포지토리 서버에 제출) 이것은 매우 나쁜 동작이지만 git에서는 브랜치가 오프라인이기 때문에 제출한 후 버그를 수정하기 위해 다시 전환하고 다시 전환한 다음 기능이 완료된 후 제출 레코드를 병합하면 모든 것이 완벽합니다. .

Answer 2

양 당사자가 서로 다른 파일을 변경하거나 동일한 파일의 다른 부분을 변경하는 경우 git이 자동으로 이를 병합할 수 있습니다.

동일한 파일의 동일한 부분이 수정되면 git은 자동으로 병합할 수 없습니다. 이 상황을 "충돌"이라고 합니다. Git은 두 당사자의 최신 버전을 나열한 다음 병합을 수행한 사람을 나열합니다(예: 예 C), 수동으로 편집하세요.

실제 개발에서는 두 사람이 이 파일에 기능만 추가하면 자동으로 병합될 수 있는데, 주로 같은 줄을 수정할 때 충돌이 발생합니다.

보충 답변:

많은 소개에서 git이 오프라인으로 커밋될 수 있다는 점을 강조합니다. 이는 svn과 비교하기 위한 것입니다. svn에서는 서버에만 완전한 저장소가 있고 클라이언트의 코드 기록은 완전하지 않습니다. git의 각 클라이언트는 완전한 저장소이며 푸시 및 풀 작업은 실제로 여러 개의 완전한 저장소 간의 동기화입니다.

이것의 장점은 서버가 중단되거나 손실되는 것을 두려워하지 않는다는 것입니다. 모든 사람은 완전한 버전 라이브러리를 가지고 있습니다. 이는 Linux가 git을 개발하는 출발점이기도 합니다. 더 나쁜 것은 모든 사람이 코드(기록의 모든 수정 사항)가 실수로 유출될 수 있는 완전한 저장소를 가지고 있다는 것입니다.

Answer 3

드디어 제가 잘 대답할 수 있는 질문이 생겼습니다

먼저 질문의 가설에 대해 이야기해 보겠습니다.

C는 6일째부터 리모컨 조작을 중단하고 혼자 놀기 시작했습니다. 분산되지 않음은 네트워크가 사용 가능한 경우를 의미하며 며칠 후에 원격 장치와 동기화되지 않는다는 의미는 아닙니다.

파일 이름이

이므로 이 파일은 거의 수정되지 않습니다(또는 동일한 줄이 거의 수정되지 않음). PythonGlobalFunction.php의 과 유사하며 때로는 새로운 파일일 수도 있습니다. 버전이 출시될 때만 setup.py 변수를 수정하세요. versionGIT의 브랜치 개념에 대한 개인적 이해는 하나 이상의 브랜치를 기반으로 더 빠른 공동 개발이 가능하다는 것입니다. 예를 들어 창고

에

라는 브랜치가 있으면 A, B, C가 됩니다. 때로는 이 공통 브랜치 foo를 기반으로 로컬 브랜치가 만들어지기도 합니다. 예를 들어 A의 로컬 브랜치는 master, C의 로컬 브랜치는 master이라고 합니다. 그게 나오나요? a-dev 으아아아 b-devc-dev둘째, 질문에서 언급한 합병에 대해 이야기해보겠습니다.

C가 을 기반으로 로컬 브랜치를

만들면 C는 로컬 브랜치에 영향을 주지 않고 항상 로컬 마스터 브랜치를 업데이트할 수 있습니다

(이때 항상 master에 있을 수 있습니다. 지점): c-dev 으아아아 c-dev그럼 로컬 c-dev이 업데이트되면

에는 어떻게 반영되나요? 간단합니다. GIT가 이미 생각해 냈습니다.

으아아아 master위 단계를 통과한 후 발생할 수 있는 상황은 두 가지뿐입니다. 1. 병합 충돌 발생, c-dev 실패 2. 충돌 없음(자동

일 수 있음), 로컬

최신 상태가 다릅니다. 로컬 rebase 병합 merge master1이 발생하는 경우 GIT는 충돌을 자동으로 해결하지 않지만 자동으로 병합을 시도할 수 있습니다(c-dev). 실패할 경우 일반적으로 동일한 내용을 수정하는 다른 제출물을 충돌이라고 합니다. 동일한 파일의 파일. 내용의 줄(여러 줄)은 개발자가 직접 충돌을 해결해야 합니다.

merge개인 요약

Branch는 다른 중앙 집중식 버전 관리 시스템과 구별되는 GIT의 킬러 기능입니다(

).

GIT의 분산 기능은 GIT의 좋은 브랜치 기능과 분리될 수 없습니다.

Answer 4

충돌이 발생하면 SVN은 한 줄씩 비교하고 Git은 줄 추가, 삭제, 줄 수정 등의 작업을 기록하므로 병합 작업이 더 쉽습니다

Answer 5

당신이 언급한 문제는 지점을 통해서만 해결될 수 있습니다

Answer 6

간단히 말하면 자동 병합이 가능할 수도 있고 불가능할 수도 있습니다.
Git의 각 커밋은 diff를 저장합니다. 커밋을 표시하고 살펴볼 수 있습니다. diff는 원래 수정된 줄 전후의 여러 줄을 일치시키려고 시도합니다. 일치할 수 있으면 diff가 자동으로 병합될 수 있습니다.
예를 들어 C의 패치가 다섯 번째 줄의 값을 수정하면 커밋되지 않습니다. A와 B는 GlobalFunction.php에 새로운 기능을 추가했습니다. 이 기능은 C가 병합될 때 Cherry-Pick을 통해 병합을 완료할 수 있습니다.
두 당사자 모두 동일한 장소를 수정한 경우 충돌을 수동으로 해결해야 합니다.