Git Merging - 동시에 2 개의 분기가 병합되는 경우

Question

git에서 병합하는 것에 대해 명확하지 않은 이해가 있습니다. 정확하게 이해하고 싶습니다.

예를 들어, 이미 100 개의 LOC가있는 master 브랜치에 파일 F가 있습니다. 나는 master로부터 branch A를 만들고, 50 LOC를 쓰고, 101 번째 줄에서 150 번째 줄까지 시작합니다. 지점 A를 마스터로 병합하라는 병합 요청을 만듭니다. 따라서 분기 A가 병합 될 경우 마스터의 파일 F는 150을 갖습니다. LOC

분기 A가 아직 마스터에 병합되지 않았다고 가정 해 봅시다. 그리고 나는 master로부터 새로운 branch B를 생성한다. 나는 또한 50 LOC를 쓰고, 101 번째 줄부터 150 번째 줄까지 시작한다. (왜냐하면 지점 A는 아직 병합되지 않기 때문이다.) 그리고 나는 또한 지점 B

의 MR을 만들

어떻게됩니까, 2 명 2 MR을 등을 검토하는 경우 :

그들은 같은 시간에 2 MR을 병합

1. ? 두 지점이 101 번에서 150 번 줄에 합류되기를 원하기 때문에 마스터는 갈등이 있습니까?

2. 브랜치 A가 먼저 병합 된 경우 마스터에 이미 150 LOC가 있음을 의미하지만 브랜치 B는 여전히 100 LOC가있는 마스터에서 생성 되었기 때문에 101 번째에서 150 번째 라인에서 시작됩니다. B가 병합 될 때 충돌이 발생합니까? 아니면 Git이 어떻게 처리합니까? 충돌과 전략은 병합 : 사전에

감사합니다 (난 그냥 경우에 어떤 사람들은 플래그이 질문을하려고, 물건을 파악하려면, 트롤 아니다) 명확히하기

Answer 1

뭔가 생각 git 자체의 개념. "병합 요청", OTOH는 gitlab (그리고 다른 repo 호스트는 비슷한 개념을 가짐) 개념이지만 git 자체에는 아무런 의미가 없습니다. 당신의 질문은 git에 대해 가장 잘 대답합니다; 병합 요청은 git에서 병합 작업을 시작할 수있는 하나의 워크 플로임을 알 필요가 있습니다. 그럼 두 부분으로 질문을 보자 :

순차 병합을

짧은 답변을 : 아마 충돌이있을 수 있습니다.

충돌이 있는지 여부는 병합 전략에 따라 다릅니다. 내 테스트는 101-150 줄에 대체 변경 사항이 표시되므로 대개 충돌이 있음을 나타냅니다. 두 세트의 변경 사항이 모두 추가되었으므로 두 세트의 줄을 충돌없이 추가 할 수 있다고 생각할 수 있습니다. 당신은 union 병합 드라이버를 사용하여 그렇게하려고 할 수 있습니다; http://kernel.org/pub/software/scm/git/docs/gitattributes.html을 참조하십시오

명령 행 인수를 통해 다른 방법으로 병합을 해결하도록 git에 지시 할 수 있지만이 명령은이 조건이 설정된 하나의 파일뿐만 아니라 전체 커밋에도 적용되므로 일반적으로 에. .gitattributes을 사용하면 (전체) 파일에 대한 접근 방식이 올바른지 미리 알 수 있다면 하나의 파일 만 병합하는 방법에 영향을 줄 수 있습니다.

따라서 merge의 동작을 변경하는 방법에 대한 많은 옵션이 있습니다. 원하는 결과를 알지 못하고 너무 많아서 여기에 자세히 나와 있지 않습니다. 하지만 일반적으로 기본 병합 설정을 사용하고 문제가 발생하면 충돌을 해결하는 데는 어쨌든 효과적입니다.

동시 병합

이 병합은 하나의 repo에서 "동시에"발생하는 것은 정말 불가능합니다. 호스트가 호스팅 된 (origin) 저장소에서 병합을 시작하는 방법을 제공하는 경우 - 실제로 누군가는 알지 못하지만 논증을 위해 - 먼저 병합을 완료해야하고 다른 병합은 완료해야합니다. 해당 병합 결과를 시작점으로 봅니다. 그 대답의 이전 부분을보십시오.

한 사람이 하나의 레포에서 한 병합을 수행 할 수 있고 다른 사람이 두 번째 레오에서 다른 병합을 수행 할 수 있고 두 사람이 원격으로 동기화를 시도 할 때 충돌이 발생할 수 있습니다. 그리고 여기에이 보일 수 있습니다 방법은 다음과 같습니다

이

(I 사실 있으리라 믿고있어이 예를 통해 그 참고 병합 - 즉, 무엇을 당신이 no-ff 옵션을 사용하는 경우 병합 그래프는 간단 수 있습니다 일어날 것,하지만 결과가 될 것입니다. 동일까지 충돌이가는대로, 빨리 감기 병합이 허용 된 경우.)

는 그래서 REPO 모든 커밋은 하나의 파일을 포함

  B <--(branch_B) 
     /
x -- x -- O <--(master) 
      \ 
      A <--(branch_A) 

로 시작. O에는 파일에 100 줄이 있습니다. A 및 B은 각각 파일 끝에 50 줄의 새 줄을 추가합니다.

이제 Alice가 branch_A을 병합하고 Bob이 로컬 레포에 각각 branch_B을 병합합니다. 그래서 앨리스는

  B <--(branch_B) 
     /
x -- x -- O -- MA <--(master) 
      \/
      A 
      ^-(branch_A) 

을 가지고 있으며, 밥이 자신의 작품을 공유하려면

  v-(branch_B) 
      B 
     /\ 
x -- x -- O -- MB <--(master) 
      \  
      A <--(branch_A) 

을 가지고, 그들은 서로 pushorigin을 시도 할 것이다; merge과 마찬가지로 정확히 동일한 순간에 푸시를 시작하려고해도 다른 하나가 시작되기 전에 먼저 완료됩니다.

그래서 앨리스가 그녀를 밀어 넣고, origin은 그녀의 로컬처럼 보입니다. Bob이 푸시하려고 시도하면 master이 master (origin) 뒤에 있기 때문에 오류가 발생합니다 (일반적인 매핑을 가정하고 업데이트되면 origin/master 뒤에 표시 될 수 있음).

그래서 Bob은 push이되기 전에 pull (또는 fetch 및 merge)이어야합니다. 가장 명확하게 설명하기 위해 그가 fetch라고 가정 해 봅시다. 이제 그는

 v-(branch_B) 
      B 
     /\ 
x -- x -- O -- MB <--(master) 
      |\ 
      | MA <--(origin/master) 
      |/ 
      A <--(branch_A) 

을 가지고 있으며 pull의 효과를 완료하는 데, 그는 origin/master master로 병합 할 필요가 - 그래서이 경우에도 처음 적용되는 "순차적 병합"시나리오로 요약된다. 실제로, 빠른 전진 병합을 사용하여 동일한 시나리오를 추적하는 경우 모든 repro에서 한 명의 사용자가 모든 작업을 완료 한 경우 여기에 필요한 "두 번째 병합"이 "두 번째 병합"과 완전히 동일하다는 것이 명확 해집니다.