스쿼시 풀 요청이 git의 병합 알고리즘을 위반합니까?

현재 git 코드를 관리하기 위해 VSTS를 사용하는 회사에서 일하고 있습니다. 브랜치를 병합하는 Microsoft의 "권장"방법은 "스쿼시 병합"을 수행하는 것입니다. 즉, 해당 브랜치에 대한 모든 커밋이 모든 변경 사항을 통합하는 하나의 새로운 커밋으로 스쿼시됩니다.

문제는 한 백 로그 항목에 대해 한 분기에서 일부 변경을 수행 한 다음 즉시 다른 백 로그 항목에 대해 다른 분기에서 변경을 시작하려는 경우 해당 변경은 첫 번째 분기의 변경 세트에 따라 어떻게됩니까?

해당 백 ​​로그 항목에 대한 브랜치를 만들고 첫 번째 브랜치를 기반으로 할 수 있습니다. 여태까지는 그런대로 잘됐다. 그러나 두 번째 분기에 대한 풀 요청을 만들 때가되면 첫 번째 분기가 이미 마스터로 병합되었으며 스쿼시 병합으로 수행 되었기 때문에 git은 많은 충돌을 표시합니다. 이것은 git이 두 번째 브랜치를 기반으로 한 원래 커밋을 보지 못하기 때문에 하나의 큰 스쿼시 병합을 보았 기 때문에 두 번째 브랜치를 병합하기 위해 마스터로 첫 번째 브랜치의 모든 커밋을 재생하려고합니다. 스쿼시 병합의 상단에 많은 충돌이 발생합니다.

그래서 내 질문은이 문제를 해결할 수있는 방법이 있습니까 (하나의 기능 지점을 다른 지점에서 기반을 두지 않고 내 워크 플로우를 제한하지 않는 것 이외) 또는 스쿼시 병합이 git의 병합 알고리즘을 깨뜨리는 것입니까?

Git으로 커밋

• 불변이다
• 유향 비순환 그래프를 형성합니다.

스 쿼싱은 커밋을 결합하지 않습니다. 대신, 여러 다른 커밋의 변경 사항으로 새로운 커밋을 기록합니다. 리베이스는 비슷하지만 커밋을 결합하지 않습니다. 기존 커밋과 동일한 변경 사항으로 새 커밋을 기록하는 것을 기록 다시 작성 이라고 합니다. 그러나 기존 커밋은 변경할 수 없으므로 "대체 이력 작성"으로 이해해야합니다.

병합은 공통 조상 커밋에서 시작하여 두 커밋 기록 (분기)의 변경 사항을 결합하려고합니다.

그래서 당신의 역사를 봅시다 :

                                 F  feature2
                                /
               1---2---3---4---5    feature1 (old)
              /
-o---o---o---A---o---o---S          master

A는 공통 조상, 1-5 원래 기능 분기, F 새 기능 분기 및 1-5와 동일한 변경 사항이 포함 된 스쿼시 커밋입니다. 보다시피, F와 S의 공통 조상은 A입니다. git에 관한 한, S와 1-5 사이에는 관계가 없습니다. 따라서 한쪽에 S를 사용하고 다른쪽에 1–5를 가진 feature2를 병합하면 충돌이 발생합니다. 이러한 갈등을 해결하는 것은 어렵지 않지만 불필요하고 지루한 작업입니다.

이러한 제약 때문에 병합 / 스 쿼싱을 처리하는 두 가지 방법이 있습니다.

• 히스토리 다시 쓰기를 사용하면 동일한 변경 사항을 나타내는 여러 커밋이 발생합니다. 그런 다음 두 번째 기능 분기를 스 쿼쉬 된 커밋으로 리베이스 합니다.

                                   F  feature2 (old)
                                  /
                 1---2---3---4---5    feature1 (old)
                /
  -o---o---o---A---o---o---S          master
                            \
                             F'       feature2
  

• 또는 기록 다시 쓰기를 사용하지 않으면 추가 병합 커밋이 발생할 수 있습니다.

                                   F  feature2
                                  /
                 1---2---3---4---5    feature1 (old)
                /                 \
  -o---o---o---A---o---o-----------M  master
  

  feature2와 master가 병합되면 공통 조상은 커밋 5가됩니다.

두 경우 모두 병합 노력이 필요합니다. 이 노력은 위의 두 가지 전략 중 어느 것을 선택 하느냐에 크게 좌우되지 않습니다. 그러나 확인하십시오

• 지점은 수명이 짧아 마스터 지점에서 표류 할 수있는 거리를 제한합니다.
• 정기적으로 마스터를 기능 분기로 병합하거나 분기를 동기화하도록 마스터에서 기능 분기를 리베이스하십시오.

팀에서 일할 때 누가 현재 무엇을하고 있는지 조정하는 것이 도움이됩니다. 이를 통해 개발중인 기능의 수를 작게 유지하고 병합 충돌 수를 줄일 수 있습니다.

스쿼시 병합은 스쿼시에 의해 제거 된 커밋이 포함 된 모든 분기에 대한 병합 알고리즘을 중단합니다. 달리 말하면, rebase는 바이러스 성입니다. 하나의 브랜치를 리베이스하는 경우 해당 브랜치에 종속 된 다른 브랜치를 리베이스해야합니다. rerere 를 사용하는 경우 로컬 리포지토리 에서 수동으로 해결 한 병합 충돌을 다시 수동으로 해결할 필요는 없지만 다른 사람이 해결 한 충돌에는 도움이되지 않습니다.

그렇기 때문에 여기에 기록되지 않은 규칙은 다른 사람이 기능 분기에 의존하지 않는 한 스쿼시하는 것이 좋습니다. 시간의 90 % 정도입니다. 그렇지 않으면 스트레이트 병합은 모든 사람이 문제를 피하는 데 도움이됩니다.