나는 Integration Manager Workflow에 대해 읽었으며 개발 프로세스에 적합합니다 (프로젝트 저장소의 커밋 전에 동료 개발자의 작업을 검토하는 프로젝트의 책임 개발자 중 한 명).Git Integration Manager 워크 플로 - 하나 또는 여러 개의 리포지토리?
그러나 한 가지는 분명하지 않습니다.
this chapter (섹션 "개인 작은 팀")에서, 그러나, 그들은 것 : 프로 망할 놈의 책에서이 시각화에 밀어 각 개발자는 자신의 (원격) 저장소를 가지고 있지만으로 나타납니다 브랜치를 사용하여 같은 종류의 워크 플로우를 달성하십시오.
이 정보가 맞습니까? 어떤 전술을 사용해야합니까? 가지 또는 여러 저장소? 다른 저장소에서 작업을 가져 오는 경우 커밋 타임 라인을 유지하는 것이 더 어렵다고 생각합니다.
링크 된 워크 플로를 사용할 수 있지만 약간의 오버 헤드가 추가됩니다. 가장 큰 이점은 비동기식으로 작업 할 수 있으며 서버에 대한 액세스 만 필요하다는 것입니다.
공개 및 비공개 repos를 사용할 필요는 없습니다. devs가 로컬 리포지토리에 커밋하고 다른 리포지토리에 액세스하는 다른 devs 리포지토리에 대한 액세스 권한이 있으면 끌어 오기 기반 워크 플로를 계속 가질 수 있습니다.
예를 들면. devA가 지점 featureA에서 작업 중이라고 가정 해보십시오. 그는 자신의 지역 지부 featureA에 커밋하고 "기능 A가 준비되었습니다. 당신은 저에게서 끌어낼 수 있습니다"라고 알려줍니다. 여기에서 "git remote add devA /path/to/devA/repo.git"와 같은 리모컨으로 저장소를 설정할 수 있습니다. devA featureA를 가져 오거나 (먼저 가져 와서 코드를 확인한 다음 병합하면됩니다) 물론
이
는 예를 통해 자신의 저장소에 대한 액세스 권한이있는 것으로 가정 네트워크, ssh 또는 http.이 질문은 잠시 동안 있었지만 질문에 주어진 접근법은 유효합니다. Forking Workflow이라고합니다. 글쎄, 그것은 위의 것과 매우 비슷하며 의도와 목적에 맞춰 보이지만 적어도 전략을 명확히해야하는 좋은 글이 있습니다.
그러나 관리자가 아닌 다른 개발자에게만 중앙 저장소를 추가 할 수도 있습니다. 그러면 관리자가 추가 분기를 밀어 마스터가 마스터에 병합됩니다. – Rijk
아, 당신의 예가 매우 분명합니다. 이 워크 플로우는 하나의 저장소 (예 : 커밋 기록 손실 등)에서 모든 작업을 수행하는 것보다 단점이 있습니까? – Rijk
문제는 자식과 함께, 당신은 결코 하나의 저장소가 없다 :) 개발자는 항상 자신의 repo 것입니다. 저장소 DAG를 어떻게 보이게 할 것인가, 즉 repo를 누가 푸시하는지, 누가 repo 등을 가져 오는 지에 대한 문제 일뿐입니다. – ralphtheninja