github 팀 워크 플로-갈래?


21

우리는 현재 Subversion을 사용하는 소규모 웹 개발자 팀이지만 곧 github으로 전환하고 있습니다.

다양한 유형의 github 워크 플로우를보고 있으며 각 개발자를 위해 github의 전체 포크 개념이 우리에게 좋은 아이디어인지 확실하지 않습니다.

우리가 포크를 사용하면 각 개발자가 자신의 개인 원격 및 로컬 리포지토리를 갖게된다는 것을 알고 있습니다. 변경 세트를 어렵고 복잡하게 만드는 것이 걱정됩니다. 또한, 가장 큰 관심사는 각 개발자에게 2 개의 리모컨, 즉 오리진 (원격 포크)과 업스트림 (메인 리포지토리에서 변경 사항을 "동기화"하는 데 사용)을 갖도록하는 것입니다. 그것이 그렇게 쉬운 방법인지 확실하지 않습니다.

이것은 https://github.com/usm-data-analysis/usm-data-analysis.github.com/wiki/Git-workflow에서 설명한 워크 플로와 비슷합니다.

우리가 포크를 사용하지 않는다면, 중앙 리포지토리를 사용하여 작업중인 각 작업에 대한 브랜치를 생성하고 동일한 리포지토리의 개발 브랜치에 병합하면 좋습니다. 즉, 지점 병합을 제한 할 수 없으며 중앙 저장소에 많은 지점이 있으면 약간 지저분해질 수 있습니다.

두 워크 플로를 모두 시도한 팀의 제안이 있습니까?


3
포크 또는 포크
Lukasz Madon

답변:


9

포크에 대한 당신의 두려움은 SVN의 별이 아닌 병합에서 비롯된 것이라고 생각합니다. 문제를 일으키는 것은 포크가 아니기 때문입니다. 그것은 병합입니다.

다이빙-실제로 훌륭하다는 것을 알게 될 것입니다! 오버 포킹 할 필요는 없지만 (모든 파일을 변경할 때마다 포크하지 않아도 됨) 기능을 포크하고 다시 병합 할 수 있습니다.

GitHub을 소스 제어의 많은 핵심 개념에서 개선 할 가치가있는 여러 버전으로 생각하십시오.

"안정된"지점과 "능동적 인 개발"포크의 개념은 갈망하는 경우 주저하는 경우 이러한 많은 문제를 다룹니다. :피


19
"fork"의 모든 인스턴스를 "branch"로 바꾸면 동의합니다. 그러나 문제는 두 개 이상의 원격 저장소를 포크하고 처리하는 것에 관한 것입니다.
David Harkness

8

우리는 svn에서 매우 집에있는 개발자와 함께 두 가지를 모두 시도했습니다. 그리고 이미 공동 작업 권한을 가지고 서로를 신뢰하는 많은 개발자라면, 하나의 중앙 리포지토리를 유지하고 그 리포지토리의 공동 작업자로 모든 것을 추가하는 것이 더 쉽다는 것을 알게 될 것입니다.

우리는 여전히 개인 포크를 사용하지만, 이는 일반적으로 이국적인 변화 나 1 인 테스트로 나머지는 일반적으로 관심이 없지만 어쨌든 원격으로 저장하려고합니다.

나는 하나의 중앙 저장소로 시작하고 잠시 동안 git과 함께 일할 것입니다. 아마도 개인 포크가 자랍니다. 어느 쪽이든 괜찮습니다.


6

자식에서 포크는 실제로 또 다른 지점입니다. Fork-to-each-developer 워크 플로를 사용하면 각 개발자에게 개발 변경 사항을 추적 할 수있는 공개 (원격) 지점이 있어야합니다. 이는 개발자간에 직접 (피어 투 피어) 공동 작업을 수행하는 데 도움이됩니다. 어쨌든 각 개발자의 변경 사항을 중앙 저장소에 병합해야하므로 이로 인해 오버 헤드가 많이 있다고 생각하지 않습니다.


3

2-3 명의 개발자로 구성된 소규모 팀의 경우 리포지토리의 분기를 사용하여 수정 및 기능을 관리해도됩니다. 문제는 개발자보다 개발자가 많고 개발중인 기능 및 수정이 더 많은 경우입니다.

이 경우 Github의 주요 리포지토리에는 수백 개의 지점이 있습니다. 일부는 오래되고 잊혀지고 풀릴 것입니다.

또한 리포지토리에있는 공유 지점에서 누군가가 강제로 푸시하는 공동 작업에 문제가 있습니다. 즉, 강제 푸시가 기록을 다시 작성하기 때문에 아무도 해당 브랜치에서 제대로 협업 할 수 없습니다.

리포지토리를 포크하면 진행중인 분기와 진행중인 분기를 쉽게 추적 할 수 있습니다. 메인 리포지토리를 깨끗하게 유지합니다.

그러나 테스트 인프라는 기본 리포지토리를 사용하고있을 수 있으므로 지점을 업스트림으로 푸시하지 않으면 분기 된 리포지토리의 변경 사항을 테스트하기가 더 어려울 수 있습니다. 분기 및 포크가 가장 좋은시기를 알아내는 것은 까다로울 수 있지만 일반적으로 팀에 4 명 이상이 있고 많은 수정 사항과 기능이있는 경우 포크가 최선의 선택입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.