정기적 인 git 및 github을 사용하면 마스터 브랜치로 작업중 인 기능 브랜치의 풀 요청을 간단히 작성하여 코드 검토를 수행 할 수 있습니다. git-flow로 코드 리뷰를 어떻게 수행합니까? "git flow feature finish"와 같은 워크 플로를 통해 코드 검토가 실제로 발생하는 위치와 git-flow 또는 git이 해당 검토를 용이하게하는 방법에 대해 혼란스러워합니다.
답변:
우리는 최근이 정확한 문제를 발견했습니다. 우리는 git flow를 좋아합니다. (팀 토론에서 사용하는 것과 동일한 수준을 사용하여 "수준 A를 시작하겠습니다.", "지점을 만들고 체크 아웃합니다.") git은 매우 "구현"수준입니다.
팀 소유를 강조하기 위해 커밋이 아닌 검토자가git feature finish 풀 요청을 보내고 (중요한) 검토 자에 의해 병합 되기를 원하지만, 우리는 브랜치를 개발에 병합하기 때문에 문제가 있습니다 .
우리의 현재 솔루션 :
이것은 흐름을 끝내지 않기 때문에 브랜치를 직접 삭제해야한다는 단점과 함께 우리의 관행과 일치합니다. 다음 단계는 아마도 git flow의 일부를 다시 구현하여 (주로 git 명령을 연결하는 것과 관련하여) 이것을 고려하여 (병합없이 마무리의 "청소"부분을 갖는) 것입니다.
내가 작업하는 팀이이를 위해 사용하는 프로세스는 다음과 같습니다.
git flow feature start module_1develop및 기능 분기 에서 풀 요청이 열립니다.module_1git flow feature finish module_1develop브랜치 (폐쇄 / 병합으로 이런 경우 GitHub의 자동 풀 요청을 표시한다)로 푸시 GitHub의일반적으로이 프로세스는 모두 원래 작성자가 수행하지만 필수는 아닙니다. 우리 팀의 모든 사람은 언제든지이 프로세스를 시작하고 선택할 수 있습니다. 기능 분기를 체크 아웃하고 프로세스를 계속하면됩니다. 누가 실행 git flow feature finish module_1하면 로컬 기능 분기의 고급 스러움이 삭제되지만 분기를 체크 아웃 한 다른 사람은 이와 같은 것을 사용하려면 수동 으로이 작업을 수행해야합니다 git branch -D feature/module_1.
핫픽스의 경우 핫픽스를 완료하기 전에 비슷한 접근 방식을 사용하고 GitHub에서 풀 요청을 만듭니다.
코드 검토를 수행하는 경우 "공식"코드가 포함 된 중앙 저장소가 있다고 가정합니다. 개발자는이 중앙 저장소에서 끌어옵니다.
Gerrit 를 사용하면 Gerrit 자체가 중앙 저장소가됩니다 (기본적으로 SSH와 HTTP 서버가 내장되어있어 사용자는 기본적으로 기존과 동일한 방식으로 상호 작용할 수 있습니다). Gerrit를 사용할 때 워크 플로우는 다음과 같습니다.
중앙 저장소를 사용하는 경우 다른 개발자는 2 단계 후에 제출 된 변경 사항을 볼 수 있습니다. Gerrit는 코드 검토 워크 플로우를 소개하므로 다른 개발자는 5 단계 후에 제출 된 변경 사항 만 볼 수 있습니다.
Gerrit은 모든 브랜치의 변경 사항 검토를 지원하기 때문에 git-flow (또는 다른 브랜치 구성표)와 잘 작동합니다.