개발자가 오프라인으로 작업 한 다음 중앙 저장소로 푸시하는 분산 환경 (GitHub 포함)에서 git를 사용했습니다. 여러 사무소가 있으므로 구조화 된 저장소 계층 구조에 대한 요구 사항이 생겼습니다. 예를 들자면 Tallinn을 기반으로하는 개발자가 원격 저장소에 푸시 할 것입니다. 우리는 또한 런던에있는 개발자들로 하여금 그들의 창고에 가게 할 것입니다. 그런 다음 두 원격 저장소간에 변경 내용을 병합하고 두 사이트의 개발자에게 다시 전달해야합니다. 따라서 계층 구조는 다음과 같습니다.GIT 저장소 계층 구조를 관리하는 방법은 무엇입니까?
Tallinn ------- London
| |
------------- -------------
| | | | | | | |
Dev Dev Dev Dev Dev Dev Dev Dev
구현 방법을 권장 할만한 사람이 있습니까?
공식 마스터를 호스트 할 도시를 선택하고 두 도시의 변경 사항을 병합하는 담당자를 두어야합니다. 각 도시에는 개발자가 맡길 수있는 자체 repo가 있으며, 결국 모든 변경 사항이 마스터 레포에 병합됩니다. 그럼 두 도시 repo의 업데이 트됩니다.
master
|
Tallinn ------- London
| |
------------- -------------
| | | | | | | |
Dev Dev Dev Dev Dev Dev Dev Dev
이것은 Linux 작동 방식과 완전히 다른 것은 아닙니다. 1 명이 주인을 통제하지만 도시 대신 일이 하위 시스템으로 나뉩니다.
탈린과 런던 간 직접 통신이 없으면 (즉, 한 중앙 repo에서 다른 중앙 repo로 직접 이동할 수 없음을 의미), 탈린 및 런던 리포의 값은 essentially fork one from another입니다.
포크는 GitHub에서 대중화 된 버전 데이터를 공유하는 사회적 방법입니다.
GitHub 포크의 기본 원리는 여전히 적용됩니다. 패치 (예 : git format-patch 사용)을 통해 데이터를 교환합니다.
Repos에 fork queue (예 : GitHub repos do)이없는 경우에도 주어진 repo에있는 다양한 패치를 관리해야하며이를 빨리 감기로 적용 할 수 있는지 확인해야합니다.
이러한 종류의 업데이트에서 전용 분기를 권장합니다.
탈린과 런던에 링크 된 어딘가에서 호스팅되는 "일반적인"저장소가 필요하다고 생각합니다. 그래서 각 팀은 밀고 당길 수 있습니다.
저는 두 저장소 세트에 액세스 할 수있는 '게이트 키퍼'를 설정했습니다. 서버 또는 다른 사람의 컴퓨터에있는 하위 디렉토리 일 수있는이 시스템은 두 사무실에서 원격으로 설정된 저장소를 가지고 있습니다. 그런 다음 양쪽에 업데이트 할 필요가 각각의 repo에 대해 :
git pull talinn
git pull london
git push talinn
git push london
참고 그 중 하나를 풀 작업은 수동 해상도를 필요로 병합 충돌이 발생할 수 있습니다. 이 작업을 수행하는 스크립트가있는 경우 개발자에게 해당 사례를 수정하여 해결해야합니다. 그래도 사람이이 작업을 너무 자주 대신 수행하게하는 것이 가능합니다.