기능 브랜치에서 마스터로 병합하기 전에 코드 검토 전략

나와 팀은 기능 분기 (git와 함께)를 사용합니다. 마스터로 병합하기 전에 코드 검토에 가장 적합한 전략이 무엇인지 궁금합니다.

1. 마스터에서 새 브랜치를 체크 아웃하고 fb_ # 1이라고 부를 수 있습니다.
2. 몇 번 커밋하고 다시 마스터로 병합하고 싶습니다.
3. 내가 병합하기 전에 누군가가 코드를 검토해야합니다

이제 두 가지 가능성이 있습니다.

1 일

1. 나는 병합 # 1 fb_하는 마스터 ( 하지 - - 날짜 가능한 한 그것을 만들 마스터 fb_ # 1)
2. 동료가 마스터 헤드와 fb_ # 1 헤드 간의 변경 사항을 검토합니다.
3. fb_ # 1이 정상이면 fb_ # 1을 마스터에 병합합니다.
4. 장점 : 리뷰에 쓸모없는 코드가 없습니다.
5. 단점 : 다른 사람이 "1"사이에 무언가를 합치면 그리고 "2." 변경 사항은 다른 검토에 속하지만 검토에 나타납니다.

2 위

1. 팀원이 결제 시점 (git merge-base master fb_ # 1)과 fb_ # 1 헤드 간의 변경 사항을 검토합니다.
2. 장점 : 기능 분기에서 작업하는 동안 변경된 내용을 정확히 볼 수 있습니다
3. 단점 : 리뷰에 쓸모없는 코드가 나타날 수 있습니다.

어느 쪽이 더 낫고 왜 생각 하십니까? 더 적합한 다른 접근법이 있습니까?

첫 번째 옵션의 변형이 있습니다.

1. 마스터를 fb_ # 1에 병합하여 (fb_ # 1이 아니라 마스터) 가능한 한 최신 상태로 만듭니다.
2. 팀원 이 합병 한 시점에서 마스터 와 fb_ # 1 헤드 간의 변경 사항을 검토합니다.
3. fb_ # 1이 정상이면 fb_ # 1을 마스터에 병합합니다.
4. 병합이 잘되었는지 빠른 확인

예.

... ma -- ... -- mm -- ... -- mf  <- master
      \            \         /
       f1 ... fn -- fm -----      <-- fb_#1

어디에:

• ma 는 master와 fb_ # 1의 조상입니다.
• fn 은 지점의 마지막 변경입니다
• mm 은 브랜치에 병합 할 때 마스터 / HEAD였던 커밋입니다 ( fm 제공 ).

따라서 초기 검토에서 mm 과 fm 을 비교 한 다음 mf 를 병합 한 후 1 ~ 3 단계 동안 마스터에서 큰 변화가 없는지 빠르게 확인 합니다. 이것은 초기 검토를위한 모든 장단점을 가지고있는 것 같습니다.

이것은 검토가 마스터에 적용되는 일반적인 변경 빈도와 비교하여 신속하다고 가정하므로 fm-> mf 는 종종 빨리 진행됩니다.

그렇지 않은 경우 어떤 이유로 든 단점은 초기 검토에서 병합 후 검토로 이동하기 때문에 마스터에 직접 병합하고 단일 검토를 수행하는 것이 더 간단 할 수 있습니다.

3 위

• 당신은 리베이스 모두 메이크업은 - - 날짜에 마스터 분기를하고 변경을 따로 보관 해 두십시오.

  이것은 지점의 새로운 역사를 만듭니다. 동일한 ID를 가진 새로운 ID를 가진 새로운 개정판이지만 최신 마스터에서 파생되며 이전 개정판에 링크되지 않습니다. 예를 들어 충돌 해결에서 실수를했기 때문에이를 참조해야하는 경우 이전 개정판은 여전히 ​​"참조"에서 액세스 할 수 있습니다. 그 외에도 그들은 무가치합니다. Git은 기본적으로 3 개월 후에 reflog를 제거하고 이전 개정을 버립니다.

• 대화식 리베이스 ( git rebase -i및 git commit --amend)를 사용 하여 논리적으로 닫힌 변경을 수행하도록 변경 사항을 재 배열, 편집 및 정리합니다.

  다시 한 번 새로운 기록을 작성합니다. 이번에는 검토 중에 변경 사항을 가장 적절하게 재구성 할 수있는 이점이 추가되었습니다.

• 장점 :

  • 쓸모없는 코드가 없습니다
  • 기능 브랜치에서 작업하는 동안 변경된 내용을 정확히 볼 수 있습니다
• 단점 :
  • 조금 더 일
  • 이미 병합되었거나 공유 한 항목을 리베이스하지 않도록주의해야하며 수신자가 다시 감을 것으로 예상하지 않습니다.

일반적으로 추가 작업은 코드를 먼저 철저히 검토하여 많은 문제를 겪을 수 있음을 의미합니다.

이것이 Linux와 Git이하는 일입니다. 그리고 검토를 위해 제출 된 일련의 20 ~ 25 개의 패치가 해당 프로젝트에서 여러 번 다시 작성된 것을 보는 것은 드문 일이 아닙니다.

실제로 리눅스는 프로젝트 초기부터 버전 선택이 tarball과 패치 일 때이 작업을 수행했다. 몇 년 후 Linus가 git을 만들기 시작했을 때, 이것이 rebase명령 을 구현 한 주된 이유였으며 대화식 변형입니다. 또한 git은 author 와 committer 라는 별도의 개념을 가지고 있습니다. 작성자는 수정본을 처음 만든 사람이고 커미터는 마지막으로 수정 한 사람입니다. Linux와 Git에서 패치는 여전히 이메일로 제출되므로 두 사람은 거의 같은 사람이 아닙니다.

GIT가 SCM 방법론의 구현보다 SCM 프레임 워크의 구현보다 더 많기 때문에 실제로 세 번째 가능성이 있습니다. 이 세 번째 가능성은을 기반으로 rebase합니다.

rebaseGIT 부속 명령은 (일반적으로 토픽 브랜치의 팁 당신의 분기 지점에서 커밋의 일련의 소요 topic)와 (일반적으로 통합 지점의 끝, 예에 다른 곳에서 그들을 재생을 master). 이 rebase부속 명령은 새로운 커밋을 생성하여 검토하기 쉬운 형태로 커밋을 재 배열 할 수있는 기회를 제공합니다. 이것은 이전 topic에 통합 분기의 최상위에 뿌리를 둔 것처럼 보이는 새로운 일련의 커밋을 생성합니다 . 이 새 브랜치는 여전히 topicGIT에 의해 호출 되므로 이전 참조는 삭제됩니다. 비공식적으로 topic-0지점의 원래 상태 topic-1등 다양한 리팩토링에 레이블을 지정 합니다 .

topic지사에 대한 제안은 다음과 같습니다 .

1. (선택 단계) 당신은 대화 형 주제 지점을 리베이스 topic의 분기 지점에 (참조 --fixup에 대한 옵션 commit과 -i와 --autosquash의 옵션을 rebase당신에게 검토 쉬운 방법으로 커밋을 다시 할 수있는 기회를 제공하는). 결과적으로 분기가 발생 topic-1합니다.

2. 통합 브랜치 상단에있는 토픽 브랜치를 리베이스하면 병합을 수행하는 것과 비슷하지만 소프트웨어 엔지니어링 아티팩트 인 병합으로 히스토리를 "오염시키지 않습니다". 결과적으로 분기가 발생 topic-2합니다.

3. topic-2의 팁에 대해 검토하는 팀원 에게 보냅니다 master.

4. topic-2괜찮다 면 마스터에 병합하십시오.

참고 분기 가 커밋 트리를 가리키는 분기 는 모두 GIT에 의해 동일하게 호출되므로 프로세스가 끝날 때 분기 만 topic-2GIT에 이름을 갖습니다.

장점 :

• 쓸모없는 코드가 없습니다.
• 가짜 "외국 합병"리뷰는 없습니다 (1 차에서 설명한 현상).
• 커밋을 다시 작성하는 기회는 깔끔합니다.

단점 :

• 대신 한 가지로 topic-0,이 세 가지의 유물입니다 topic-0, topic-1그리고 topic-2(가) 트리를 커밋이 생성됩니다. (언제라도 GIT에는 이름이 하나만 있습니다.)

첫 번째 시나리오에서«누군가 "1"사이에 무언가를 병합 한 경우 "2"는 분기 지점 생성과 병합하기로 결정한 시간 사이의 시간을 나타냅니다. 이 시나리오에서«누군가 "1"사이에 무언가를 병합 한 경우 "2."»는 리베이스와 병합 사이의 시간 간격을 나타내며 일반적으로 매우 짧습니다. 따라서 내가 제공하는 시나리오에서는 master워크 플로우를 크게 방해하지 않으면 서 병합 시간 동안 분기를 «잠글»수 있지만 첫 번째 시나리오에서는 실용적이지 않습니다.

체계적인 코드 검토를 수행하는 경우 적절한 방법으로 커밋을 재배 열하는 것이 좋습니다 (선택적 단계).

중간 지점 아티팩트를 관리하는 것은 저장소간에 공유하는 경우에만 어려움이 있습니다.