Git 운영 체제에 대해 고찰

Outline

머리말

master는 개발 브랜치가 아니다! !

프로젝트 매니저가 master를 관리하라! !

코멘트는 소스가 아니고, 풀리크내에 쓸 수 있다! !

최종 Git 관리 구성

머리

일에서 이용하고 있던 Git 운용 체제에 납득하지 않고, 어떤 운용 방법이 좋은가를 고찰했으므로, Qiita에 정리하려고 생각했습니다.

master는 개발 브랜치가 아닙니다! !

자신의 개발 환경이 master 브랜치만으로 개발을 하고 있습니다. 아니, 그럼, SVN과 변함없는. 브랜치의 개념 이해?

Git master 브랜치 위치 지정

릴리스 가능한 상태만 관리

특정 브랜치로부터 병합하는 것에 의해서만 갱신된다

직접 커밋해서는 안된다는 제약을 가진다

버전 별 태그는 여기에서 태어납니다

당연히 master 브랜치는 기본이지만,이 브랜치 모델의 master는 개발의 주축이 아닙니다. 이 마스터는 이제 고객에게 제공하는 가치 자체를 나타내는 브랜치입니다.

master는 주축의 소스이며, 개발하는 소스가 아닙니다! !

프로젝트 매니저가 master를 관리하라! !

master만으로 관리하고 있다면, developer는 master를 괴롭힌다.
방금 말했지만 Git의 개념을 이해하지 못했습니다.
기본적으로 PM은 소스 리뷰를 수행하고 git merge를 수행합니다.
PM 분들 최선을 다하십시오.

코멘트는 소스가 아니고, 풀리크내에 쓸 수 있다! !

GitHub/GitLab/GitBucket에는 풀릭(pull request) 기능이 있습니다.
풀릭에서는 변경한 부분이 색으로 구분되어 있어 거기에 대한 코멘트를 기술할 수 있습니다.
색으로 구분하여 UI에 의한 차이를 보더라도 가독성이 향상됩니다.

GitLab의 리포지토리를 브라우저에서 열었다 예 입니다.

최종 Git 관리 구성

PM

마스터 관리

git merge

소스 리뷰

PG

developer 사용

git push

pull request

대충 이런 느낌입니까.
PM과 PG는 나누어 생각하지 않으면 Git의 의미도 권한의 의미도 이해하지 못한다.

참고

Git 브랜치에 대한 기본 요약