자주 복잡한 병합 충돌이 문제의 징후입니까?

우리 팀에서는 Git을 소스 제어로 사용합니다. 우리는 거의 독립적이지만 겹치는 몇 가지 코드 영역을 가지고 있습니다. 최근에 소스 제어 사용에 대한 워크 플로우 및 접근 방식에 대해 논의했습니다. 기능 분기 워크 플로를 사용하여 홍보 할 때 제기되는 불만 중 하나 는 사람들이 종종 복잡한 병합 충돌을 일으켜 잘못 해결한다는 것입니다. 복잡하게, 나는 "해결 방법에 대해 명확하지 않다"를 의미한다. 이에 비추어, "풀 리베이스"기반 워크 플로우와 같은 다른 워크 플로우가보다 적극적으로 사용되고 있습니다.

기능 브랜치 접근법의 옹호자로서 나는 진정으로 불만을 제기하지 않습니다. 예, 로컬 피처 브랜치를 마스터 또는 어디에서나 최신 상태로 유지해야하지만 이것이 내가 본 유일한 문제에 관한 것입니다. 병합이 항상 복잡하고 보조 효과가있을 수 있다면 Git 문제보다 팀워크 문제에 가깝습니다.

이것을 생각하는 것이 맞습니까? 복잡한 병합 충돌이 좋은 것 또는 나쁜 것의 표시입니까?

문제가 코드라는 것은 불가능하지 않습니다. 코드베이스에 모듈간에 많은 상호 관계가있는 경우 모든 변경 사항이 모든 곳에서 덩굴손을 일으키고 모든 개발자가 다른 사람의 코드와 상호 작용하면 악몽이 될 것입니다.

나는 당신이 이것을 다른 방법으로 먼저 알아 차릴 것이라고 생각하는 경향이 있지만, 더 이상 그것을 볼 수 없을 정도로 익숙해 져있을 가능성이 있습니다.

"fetch-rebase-push"워크 플로우에 익숙합니다. 실제로 첫 번째, 가장 원시적 인 워크 플로이며 자습서에 설명되어 있습니다. 장점은 다음과 같습니다.

• 진정한 지속적인 통합
• 초기 충돌 관리-코드를 작성하고 테스트 한 직후
• 빠른 응답- "-밥, 당신이 쓴 입방체 보간이 재미있는 결과를 내고 있습니다. 점심 시간에 볼 수 있을까요?"
• 병합 커밋 없음-한 개발자가 everithyng을 작성한 것처럼 깨끗한 타임 라인

이제 복잡한 병합 충돌에 관한 것입니다. 나는 자주 합병 과 복잡한 합병을 어떻게 경험할 수 있는지 이해하지 못한다 . 합병증은 오랫동안 rebasing / cherry-picking하지 않고 한 달 동안 그 고독한 기능을 수행함으로써 발생합니다.

저는 개인적으로, 포괄적 인 합병 공포보다는 빈번하고 쉬운 합병 (실제로 리베이스)을 다루기를 선호합니다.

병합과 리베이스는 사람이 해결해야하는 내재적 갈등 (예 : 두 명의 개발자가 동일한 코드 줄을 변경)에 대해 똑같은 갈등을 유발해야합니다. 다른 충돌의 경우 병합은 실제로 커밋되는 경향이 있습니다. 커밋의 SHA-1을 모든 곳에서 변경하지 않기 때문입니다. 병합이 리베이스보다 더 많은 충돌을 일으키는 상태로 어떻게 관리하고 있는지 잘 모르겠지만 일부 사람들의 워크 플로우가 엉망이되어 git 작동 방법에 대한 추가 교육이 필요할 것입니다. 그들이 다른 지역의 리베이스를 할 때 다른 사람들의 병합 커밋을 제거합니까?

pull-rebase 방법의 장점과 단점은 많은 사람들이 익숙한 중앙 집중식 워크 플로와 매우 유사하다는 것입니다. 분기를 사용하기 위해 분기를 이해할 필요는 없습니다.

어쨌든 다른 사람이 사인온 할 수없는 경우 기능 분기 워크 플로우를 로컬에서만 수행하는 것이 가능합니다.

내가 작업중 인 프로젝트에는 때때로 이러한 유형의 문제가 있으며 몇 가지 요인으로 인한 것 같습니다.

• 우리는 Visual Studio를 사용하고 있으며 Visual Studio와 같은 파일은 .sln이 Guid로 가득 찬 XML 문서 (텍스트 병합에 잘 반응하지 않음) (Git은 우리보다 더 잘 이해할 수 없음)이며 쉽게 할 수 있습니다. 잘못 병합되어 파일이 손실됩니다.
• 일부 사람들은 비슷한 코드 영역에서 작업하고 있으므로 변경 사항이 강의에서 서로 바로 옆에있을 수 있습니다. 이 상황에서는 피할 수 없지만이 유형의 구성은 모든 소스 제어 시스템에서 매우 어려운 작업입니다. 팀에서 의사 소통이 잘 되더라도 사람들이 서로의 코드에 부딪 히고 충돌이 발생한다는 것을 깨닫지 못할 수도 있습니다.

Semantic Merge 가 이러한 문제 중 일부를 도울 가능성에 관심이 있지만 구문 분석 할 수있는 언어로 작업 할 때만 사용할 수 있습니다. 나는 그것을 사용하므로 그 효과를 보증 할 수 없습니다.

개발자가 순수 병합 대신 히스토리 커밋을 수정하지 않는 한 기능 워크 플로우 유형 git 모델의 충돌은 밀접하게 결합 된 코드베이스 (/ brandnew codebase) 또는 중복 된 기능 할당의 표시입니다.

기본 (마스터) 지점이 있으며 모든 사람이 기능 지점에서 작업합니다.

기능 지점에서 작업하는 데 몇 시간에서 몇 개월이 걸릴 수 있습니다.

때때로 누군가는 자신의 변경 세트를 다시 주요 지점으로 병합합니다. 팀장은 한 번에 한 사람 만 역 병합을 수행해야합니다. 이 작업이 완료되면 메인 지점에서 기능 지점으로 병합을 전달해야합니다. 모든 사람이 정방향 병합을 수행하면 다른 사람이 기본 분기로 병합을 반대로 병합 할 수 있습니다. 그렇지 않으면 너무 많은 변경 사항이 리버스 병합되고 앞으로 병합 할 때 많은 병합 충돌이 발생합니다.

용어를 명확히하기 위해 "역 병합"이란 기능 분기에서 기본 분기로 병합하는 것을 의미하고 "순방향 병합"은 기본 분기에서 기능 분기로 병합하는 것을 의미합니다. 이전에 경험 한 바에 따르면, 순방향 병합과 반대로 역방향 병합에서 더 많은 병합 충돌이 발생할 수 있습니다.

도움이 될 수있는 두 가지 : 하나는 스스로 변경하는 도구를 사용하지 않는 것입니다. 다른 탭 설정을 사용하는 두 명의 개발자가 재난을위한 레시피입니다. 둘째, 다른 위치에서 변경하십시오. 예를 들어 세 명의 개발자가 같은 파일의 끝에 코드를 추가하면 문제가 발생합니다. 다른 장소에 코드를 추가하면 훨씬 좋습니다.