github에서 팀 레포를 당길 때 git이 병합을 수행하고 충돌이 발생하지 않게합니다

Question

github에서 호스트하는 repo에서 다른 사람과 작업했습니다. 나 또는 그가 당길 때마다, git은 병합 커밋을하도록 강요하지만 (vim은 커밋 설명과 함께 열립니다), 우리는 다른 파일에서 작업하고 있지만 갈등은 없습니다.

추가 병합 커밋없이 새로운 커밋을 추가하면 안됩니까?

Answer 1

git의 기록을 그래프로 생각하십시오. 동료와 당신 모두 커밋 A를 기반으로하는 새로운 커밋을하고 있습니다. 당신 B와 그의 C라고 부르 자. 역사는 이제 다음과 같이 보일 것이다 :

B  C 
\ /
    \/
    A 

두 가지 방법이있다. 하나 병합된다

M 
/\ 
/ \ 
B  C 
\ /
    \/
    A 

을 다른 (예 git pull --rebase 통해) 리베이스된다.

B -- C -- A 

모두 장점과 단점을 가지고 : 다음 예제에서는 리베이스하는 일이었다. 일반적으로 rebase는 아직 커밋을 푸시하지 않았거나 (또는 ​​다른 방식으로 공유 한 경우) 제대로 작동합니다. 즉, B 만 가지고있는 유일한 사람입니다. 그렇지 않은 경우 rebase가 발생하면 매우 성가신 문제와 병합하는 것이 더 나을 것입니다.

Answer 2

각 커밋은 트리 전체의 상태를 기록하므로 서로 다른 분기가 동일한 파일을 수정하지 않은 경우에도 병합을 수행해야합니다.

이 경우 텍스트가 이 아니기 때문에 git은 항상 다른 분기의 변경 사항 을 자동으로 병합 할 수 있지만 그럴 것이라고 보장하지는 않습니다. any 의미 충돌. 예를 들어 한 브랜치는 라이브러리 에있는 메소드를 수정하여 추가 매개 변수를 요구할 수 있으며 다른 브랜치는 해당 메소드에 콜을 새로 도입합니다. 병합에서 충돌을보고하지는 않지만 추가 변경없이 결과 코드 이 작동하지 않습니다. 누군가가 명시 적 병합 커밋을 수행하면 작동하지 않는 커밋이 이루어지기 전에 그러한 충돌이 발생할 수 있으므로 이 잡힐 가능성이 있습니다. 실제로 이 병합을 수행 할 때마다 이러한 유형의 충돌을 검사하지는 않지만 장기 실행 분기로 병합을 완료 한 작업 만 수행하면 병합이 수행되는 것이 덜 부담 스럽습니다 항상 병합을 완료 한 후 테스트 스위트를 실행하는 습관을 들여야합니다.