某草草2017-05-02 09:49:26
모두 공개 개발 브랜치가 있지 않나요?
dev에서 개발 브랜치를 가져옵니다. 개발이 완료되면 모두가 이를 dev에 병합합니다.
갈등을 갖고 갈등을 해결하세요.
高洛峰2017-05-02 09:49:26
우선, 기본 git은 브랜치 생성 및 병합1을 지원하므로 git 기반의 모든 코드 버전 관리 도구(예: gitlab/github)도 기본적으로 브랜치 기능을 지원합니다(gitlab에는 권한 관리 기능도 있습니다)
또한 주제 프로젝트의 주요 문제는 @52lidan이 말했듯이 브랜치가 없습니다dev
로 인해 코드 버전 관리에 혼란이 발생한다는 것입니다(A, B 또는 C 브랜치가 가장 중요한가요?) . 주제는 :
프로젝트에는 다음 브랜치가 있어야 합니다
master
: 프로덕션 환경에 공식적으로 출시될 수 있는 코드 브랜치(보호됨)2
dev
: 개발 및 예비 테스트 후 작업 코드 브랜치를 사용하여 모든 사람의 작업을 병합하고 버그를 수정합니다(보호됨)
작업별로 새 브랜치를 생성하면 작업이 사람을 따르는 대신 작업이 따라옵니다. 즉, 원격 라이브러리에서는 작업이 브랜치가 하나만 있고 모든 사람이 로컬로 가져옵니다. 이 작업의 작업은 로컬에서 커밋된 다음 작업 분기로 푸시되어야 합니다. (세 명 이상이 작업에 협력하는 것은 권장되지 않습니다. 그렇지 않으면 작업이 더 많은 분기로 분할됩니다)
protected
로 설정할 수 있습니다. owner
/master
권한을 얻은 프로젝트 참여자만 다른 사람이 제출한 제출물을 병합할 수 있습니다 merge request
↩
曾经蜡笔没有小新2017-05-02 09:49:26
선착순으로 진행하더라도 업데이트를 원격단으로 푸시하지 않고 로컬 개발이 완료된다면, 적어도 원격단에는 b가 있어야 겠죠? 그렇지 않다면 a로 병합하세요. 하지만 이건 좋지 않아요