말씀드린 대로입니다.
현재 회사에서는 gitlab을 사용하고 있으며, 대략적인 사용 과정은 다음과 같습니다.
1. 사장이 메인 창고를 생성합니다mainrepo
2. 멤버별로 복사본을 포크합니다mainrepo
. 3. 자기 자신을 위해 k의 코드에서 개발을 합니다
4. 개발이 완료된 후 병합 요청을 발행하고 상사가 코드를 병합할 때까지 기다립니다
5. 메인 창고에 새로운 업데이트가 있으면 먼저 fetch 그런 다음 이를 나만의 창고에 병합하세요
이것이 매우 번거롭고 git 브랜치의 장점이 그다지 명확하지 않은 것 같습니다.
이 작업 모델에 대해 어떻게 생각하시나요?
过去多啦不再A梦2017-05-02 09:30:16
두 가지 방법:
모두가 공동 개발, 브랜치 개발 기능을 위해 동일한 웨어하우스를 사용하며, 개발이 완료된 후 merge request을 빌드하고 code review 진행하고 최종적으로 개발 브랜치
forkmainrepo을 생성할 수도 있습니다. 개발 후 pull request를 mainrepo
으로 생성하고 코드 관리자가 이를 병합하도록 합니다
두 번째 방법의 장점:
은 mainrepo을 보호합니다. 모든 병합 작업은 pull request을 사용해야 하며, 단순히
mainrepo의 브랜치는 더 간결하고 중복 브랜치를 포함하지 않습니다.
개인이 각자의 개인창고에서 지점을 유지하며, 지점 생성 시 중복된 이름은 없습니다
저는 개인적으로 코드 기여를 강조하고 mainrepo
我想大声告诉你2017-05-02 09:30:16
글쎄요, 이건 실제로 브랜치를 활용하지 않는군요.
mainrepo 브랜치가 하나만 있어서는 안 됩니다. 개발, 기능, 핫픽스 브랜치 등은 필요에 따라 분리되어야 합니다. 이는 해당 지점에서 개발되었습니다.
过去多啦不再A梦2017-05-02 09:30:16
물론 이렇게 할 수 있습니다. 상사가 이렇게 하는 데에는 이유가 있을 것입니다.
그러나 이러한 관리 방식은 매우 중앙집권적이며 git의 분산 사상과 맞지 않아 git을 사용하는 것은 그다지 적합하지 않습니다.
ringa_lee2017-05-02 09:30:16
내가 이해하는 단계
보스 생성 라이브러리
마스터 지정 보스 합치기 가능
개발 라이브러리를 테스트 환경 라이브러리로 생성하고, 상사나 지정된 관리자만 병합할 수 있습니다.
각 개발은 자체 브랜치를 생성한 다음 이를 원격 팩토리 라이브러리로 푸시하고, 보스나 관리자는 개발 병합으로 이동하여 업스트림 브랜치를 푸시합니다.