일부 파일에 대해서만 병합 충돌을 해결하고 다른 팀에서 문제를 해결하기 위해 지점을 할당합니다.

Question

간략히 말하자면 서버 팀, 모바일 팀, ci 팀, 자동화 팀 등 다양한 기능 팀을위한 코드를 호스팅하는 하나의 Repo가 있습니다.

이제 지원 - 지점 버그 수정에서 개발 - 분기 - 지점으로 갈 때 여러 팀/개발 영역과 관련된 많은 충돌이 나타납니다. 우리는 서버 측과 모바일을 다루는 독신자가 없기 때문에 한 개인의 갈등을 해결하는 것은 정말 어렵습니다.

여기에서 질문은 어떻게 든 충돌 (예 : 서버 측) 중 일부만 해결 한 다음 중간 분기로 푸시하고 다른 팀이 자신의 개발 영역과 관련된 충돌을 해결할 수 있는지 여부입니다. 모든 팀이 모든 갈등을 해결 한 후에야 마침내 중간 지점을 합칩니다.

어쩌면 여기서 뭔가 잘못하고있는 것일 수 있습니다. 어떤 제안이라도 인정 될 것입니다 (코드베이스를 별도의 repo로 분할하는 것을 제외하고는 너무 늦었습니다).

Answer 1

git checkout -b server-team-merge dev-release-branch 
git merge support-team-fixes 
# fix the conflicts you can fix here 
git commit -m "server-team partial merge of $(git describe support-team-fixes)" 

그리고 다른 팀도 마찬가지입니다. 그것은 사소한 작업이 될 것이다, 그 결과는 당신이 한 번에 모든 작업을 수행 할 수 있습니다 진정으로 해체한다면

git checkout dev-release-branch 
git merge {server,mobile,ci,automation}-team-merge 

을하지만 한 번에 하나의 병합 불평 경우 - 그럼 가지를 부분이 병합 병합 충돌의 일부가 어떻게 해결되어야하는지에 대한 여러 가지 아이디어를 찾아냅니다.

분기를 병합 할 때 git은 그 결과를 결과 커밋에서 병합 된 병합의 올바른 병합으로 간주하므로 이후의 병합은 전체 병력을 공유로 식별하므로 수행 할 작업이 없습니다. 그러나 동일한 부모로부터 여러 개의 독립적 인 병합을 수행하면 해당 병합은 서로의 역사에있는 것이 아니며 원하는 결과를 얻을 수 있습니다. 그 결과를 병합 할 때 힘내는 위임장을보고 정확한 근거를 찾아 낼 수있다.

Answer 2

글쎄, 당신은 다음과 같이 시도 할 수 있습니다 :

1. 체크 아웃 dev-release-branch 및 support-branch와 함께 첫 번째 병합을 시작합니다.
2. 가능한 한 많은 충돌을 해결하십시오 (한 사람이 해결할 수 있음). 해당 사용자가 병합 할 수없는 파일과 디렉토리는 dev-release-branch 상태로 되돌려 야합니다.
3. 결과 상태를 a-half-of-a-merge으로 설정하고 (임시 로컬) 태그로 저장하십시오. 그 이전 병합 상태
4. -
5. 되돌리기 dev-release-branch 소스 트리의 다른 부분을 병합 할 수있어 다른 사람에 의해 support-branch와 anothermerge을 수행합니다. 다시, 2 단계에서와 같이 변경 사항을 고려하지 않습니다.
6. 병합 할 변경 사항이 있으면 3-5 단계를 반복하십시오 (확실히 다른 태그 이름을 선택하십시오).

마지막 "도메인"의 모든 충돌이 해결되었지만 병합 커밋이 아직 만들어지지 않은 경우 다른 "절반 태그"의 변경 사항을 결합 해 봅니다.

1. 현재 변경 사항 세트를 색인에 추가하십시오.
2. cherry-pick은 첫 번째 half-tag에서 변경됩니다. 병합 부모를 스위치 (가능하면 -m 1)로 지정하고 --no-commit
3. 을 지정해야이 단계에서 발생하는 모든 충돌을 해결할 수 있습니다. 희망 목록
4. 는
5. 반복 마침내 위대한 병합을 커밋 모든 half-tags
6. 에 대해 2-4 단계를 인덱스에 변경 내용을 추가 짧거나 명백 할 것이다.
7. 이제 모든 하프 태그를 안전하게 삭제할 수 있습니다.

전체 프로세스가 다소 길고 복잡하고 성가시다는 것을 눈치 챘을 것입니다. 앞으로의 릴리스에서는 프로젝트를 적절한 수의 하위 프로젝트로 분할하고 git submodules을 사용하여 큰 프로젝트로 결합하는 것이 좋습니다.