[GIT] 리모트 브랜치 Merge

리모트 브랜치 등록 및 체크아웃

• 프로젝트 기여자가 자신의 저장소를 만들고 커밋한 내용을 이메일로 보낼 경우, 해당 리모트 브랜치를 등록하고 체크아웃하여 테스트할 수 있습니다.

지속적인 개발과 리모트 저장소 활용

• 다른 개발자들과 함께 지속적으로 개발할 때, 리모트 브랜치를 등록하고 Fetch하여 사용하는 것이 효과적입니다.
• 커밋 히스토리를 알 수 있고, 3-way Merge가 자동으로 적용됩니다.

리모트 저장소 등록 없이 직접 Merge

• 저장소를 등록하지 않고도 직접 URL을 사용하여 Merge할 수 있습니다.
• 주로 함께 일하지 않는 개발자와의 작업에서 사용될 수 있습니다.

토픽 브랜치의 커밋 살펴보기

• 토픽 브랜치에 속한 커밋 중에서 현재 브랜치(master)에 속하지 않는 커밋을 확인하는 명령어입니다.

• $git log contrib --not master

커밋 간의 변경 내용 확인

• git diff 명령을 사용하여 두 브랜치(master와 토픽 브랜치) 간의 변경 내용을 확인할 수 있습니다.

• $ git diff master...contrib
  #triple-dot 구문

공통 조상 커밋 찾기

• 토픽 브랜치와 메인 브랜치의 공통 조상인 커밋을 찾아서 변경된 내용을 살펴보는 명령어입니다.

• $ git merge-base contrib master
  # merge-base로 공통 조상 커밋을 찾습니다.

• 그 결과인 커밋을 diff로 변경된 내용을 살펴봅니다.
• git diff master로만 찾을 경우 master에 새로운 커밋이 있을 경우 결과가 달라질 수 있습니다.
• 더 간단하게 triple-dot을 이용해서 비교하면 됩니다.

간단한 Merge 워크플로

• 토픽 브랜치에서 작업을 마치면 해당 브랜치를 검증하고, 안전한 코드로 판단되면 master 브랜치로 Merge하고 토픽 브랜치를 삭제하는 과정을 반복합니다.

두 개의 Long-Running 브랜치 사용

• 대규모 프로젝트에서는 최소 두 단계로 Merge하는 것이 권장됩니다. 이 예시에서는 master와 develop이라는 Long-Running 브랜치를 사용합니다.
• develop 브랜치는 새로운 수정 사항을 통합하는 역할을 하며, master 브랜치는 아주 안정된 버전을 릴리즈하기 위해 사용됩니다.
• 토픽 브랜치를 Merge하기 전에 develop 브랜치에 토픽 브랜치를 Merge한 후, 릴리즈할 만한 상태가 되면 master 브랜치를 develop 브랜치까지 Fast-forward시킵니다.

대규모 Merge 워크플로

• 프로젝트는 네 개의 Long-Running 브랜치를 운영하고 있습니다. 이 브랜치는 각각 master, next, pu (Proposed Updates), maint입니다.
• maint 브랜치는 마지막으로 릴리즈한 버전을 지원하는 브랜치로 사용됩니다.
• 토픽 브랜치의 안정성과 기능을 테스트하면서 개선해가며, 안정화된 경우 next 브랜치로 Merge하고 저장소에 Push합니다.
• 토픽 브랜치가 개선이 필요한 경우, next가 아닌 pu 브랜치에 Merge합니다. 이후에도 계속 검증을 거친 후 master 브랜치로 Merge합니다.
• master 브랜치에 Merge한 후에는 next와 pu 브랜치를 다시 master를 기반으로 재생성합니다.
• next 브랜치는 가끔 Rebase를 하고, pu 브랜치는 자주 Rebase를 진행하며, master 브랜치는 항상 Fast-forward로 Merge합니다.
• 토픽 브랜치가 최종적으로 master 브랜치로 Merge되면 해당 브랜치는 삭제됩니다.
• 토픽 브랜치가 master 브랜치에 Merge된 후, 이전 릴리즈 버전에 Patch가 필요한 경우 maint 브랜치를 사용하여 대응합니다.