여러 팀을위한 Git 워크 플로우

우리는 Git을 사용하기 시작하고 (아직 사용하지 않음) 워크 플로우를 정의하고 싶습니다.

전 세계 4 곳에 4 개의 팀이 있으며 같은 제품을 함께 개발하고 있습니다. 각 팀은 제품 코드의 일부를 소유하지만 때로는 다른 팀이 소유 한 코드를 변경해야 할 수도 있습니다.

그러한 환경에 대한 Git 워크 플로우에 대한 권장 사항이 있습니까?

이미이 기사 를 보았지만 여기서 접근 방식은 "가급적 추가 지점을 거의 생성하지 않는 것"이며 "각 사용자 스토리를위한 지점"접근 방식에 대해 더 많이 믿고 있습니다.

또한 이 기사 는 좋은 접근 방식을 제시합니다.

마스터 브랜치, 각 팀당 마스터로 정기적으로 병합하는 영구 브랜치 및 팀별 브랜치로 병합되는 사용자 별 브랜치가 있다는 점을 염두에 두었습니다. 말이됩니까, 아니면 작동하지 않습니까?

git version-control

— 이고르 옥스
소스

이 브랜칭 모델을 사용 하지만 "피처 브랜치"를 "스토리 브랜치"로 읽으면 두 번째 기사와 잘 어울립니다.

나는 10 명의 사람들이 10 개의 다른 응답으로 이것에 답할 수 있다고 확신한다. 다음은 저에게 효과적입니다. 우리는 '현재'릴리스를 나타내는 하나의 마스터 저장소가 github에 호스팅되어 있습니다. 이전 릴리스는 분기되어 있습니다 (태깅도 작동하지만). 팀 구성원은 작업중인 작업에 대한 분기를 작성하는 것이 좋습니다. 완료되면 마스터에 풀 요청을하거나 (또는 병합해야하는 경우) 다른 사람이 풀 요청을 검토하여 마스터에 병합 할 수 있습니다. 또한 지점이 병합 된 후에는 지점을 지울 책임이 있습니다.

다른 팀의 코드베이스를 구분하기 위해 서브 모듈 에 관심이있을 수 있습니다 . 그런 다음 서로의 코드베이스를 포크하고 서로의 코드 부분을 편집 할 때 패치를 보낼 수 있습니다.

— Fred Foo

@larsmans & carbonbasednerd-귀하의 의견은 답변이되어야합니다. * 8 ')

— Mark Booth

답변:

릴리스 간 기능 개발을위한 훌륭한 분기 전략이있는 성공적인 Git 분기 모델을 살펴보십시오 .

성공적인 자식 분기 모델

'개발'지점과 '기능 지점'사이의 팀 지점에 대해 하나의 추가 레벨로 비슷한 것을 구현할 수 있습니다. 또한 팀 지사가 있으면 두 팀이 팀 지사를 병합하여보다 효과적으로 협업 할 수 있습니다.

— 닉 하다드
소스

각 팀마다 리포지토리가 커널 및 중앙 리포지토리 인 Linux 커널과 같이 모든 사람이 커밋하는 하나의 전역 리포지토리와 함께 자체 버전의 리포지토리가 있다고 말합니다.

그런 다음 제품 코드를 유지 관리하기 위해 @larsmans와 같은 하위 모듈을 사용할 수 있으며 각 팀은 주로 가장 중요한 부분에서만 작업 할 수 있으며 다른 부분과 작업 해야하는 경우에는 할 수 있지만 수행 할 수는 있습니다. 서브 모듈을 업데이트해야한다는 것을 기억해야하며, 이것이 문제가있는 곳입니다 (git를 사용할 때 잘못되기가 매우 쉽기 때문에 고맙게도 쉽게 벗어날 수 있습니다).

그러나 팀이 이에 익숙하고 다른 팀 코드를 변경하고 있음을 알고 있으므로 외부 모듈을 변경하기 전에 하위 모듈 업데이트를 기억하는 것이 더 쉽습니다.

— 코요테 21
소스