두 가지 방법:

1. 모두가 공동 개발, 브랜치 개발 기능을 위해 동일한 웨어하우스를 사용하며, 개발이 완료된 후 merge request을 빌드하고 code review 진행하고 최종적으로 개발 브랜치

에 병합합니다.

2. forkmainrepo을 생성할 수도 있습니다. 개발 후 pull request를 mainrepo
   으로 생성하고 코드 관리자가 이를 병합하도록 합니다

.

두 번째 방법의 장점:

• 은 mainrepo을 보호합니다. 모든 병합 작업은 pull request을 사용해야 하며, 단순히

을 병합할 수는 없습니다.

• mainrepo의 브랜치는 더 간결하고 중복 브랜치를 포함하지 않습니다.

• 개인이 각자의 개인창고에서 지점을 유지하며, 지점 생성 시 중복된 이름은 없습니다

• 저는 개인적으로 코드 기여를 강조하고 mainrepo

에 더 많은 코드를 기여합니다.

글쎄요, 이건 실제로 브랜치를 활용하지 않는군요.
mainrepo 브랜치가 하나만 있어서는 안 됩니다. 개발, 기능, 핫픽스 브랜치 등은 필요에 따라 분리되어야 합니다. 이는 해당 지점에서 개발되었습니다.

물론 이렇게 할 수 있습니다. 상사가 이렇게 하는 데에는 이유가 있을 것입니다.
그러나 이러한 관리 방식은 매우 중앙집권적이며 git의 분산 사상과 맞지 않아 git을 사용하는 것은 그다지 적합하지 않습니다.

내가 이해하는 단계

• 보스 생성 라이브러리

• 마스터 지정 보스 합치기 가능

• 개발 라이브러리를 테스트 환경 라이브러리로 생성하고, 상사나 지정된 관리자만 병합할 수 있습니다.

• 각 개발은 자체 브랜치를 생성한 다음 이를 원격 팩토리 라이브러리로 푸시하고, 보스나 관리자는 개발 병합으로 이동하여 업스트림 브랜치를 푸시합니다.