[Git] 버전 관리의 꽃 3, 기본이자 유용한 전략

[이전 포스트]

[Git] 버전 관리의 꽃 2, 병합하기 (Merge)

 

---

 

 

Git - 브랜치 워크플로

'깃북 3.4 Git 브랜치 - 브랜치 워크플로'에 대한 발췌 및 정리입니다.

 

---

 

브랜치 워크플로우

브랜치를 만들고 Merge하는 단계를 어떻게 사용해야 할까요?

함께 유용한 몇 가지 상황을 살펴봅시다.

 

Long-Running Branch

Git은 3-way Merge를 꼼꼼하게 사용하기 때문에,

장기간에 걸쳐 하나의 주요 브랜치를 다른 브랜치와 여러 번 Merge하는 게

쉬운 편입니다.

 

이렇게 개발 과정에서 필요한 용도에 따라 브랜치를 계속 만들고 사용할 수 있습니다.

그리고 정기적으로 브랜치를 다른 브랜치로 Merge합니다.

 

이러한 접근법에 따라, Git 개발자가 많이 선호하는 워크플로우, 흐름이 하나 있습니다.

 

배포했거나, 배포할 코드만 master 브랜치에 Merge 해

안정적인 버전의 코드만 master 브랜치에 두는 것입니다.

 

개발을 진행하고 안정화를 거쳐야 하는 브랜치는

develop 이나 next라는 이름으로 추가로 만들어 사용하는 것입니다.

 

이렇게 개발을 하다보면,

커밋 히스토리 흐름에 따라

안정적인 브랜치일수록 커밋 히스토리가 뒤쳐져 있음을 알 수 있습니다.

안정적인 브랜치일수록 커밋 히스토리가 뒤쳐진다.

 

실험실에서 충분히 테스트하고 실전에 배치하는 과정으로 볼 수 있습니다.

 

각 브랜치를 하나의 “실험 환경”으로 생각

 

코드를 여러 단계로 나누어 안정성을 높여가며 운영할 수 있습니다.

중요한 개념은 브랜치를 이용해 여러 단계에 걸쳐서 안정화해 나아가면서,

충분히 안정화가 됐을 때 안정 브랜치, 즉 Master로 Merge 한다는 점입니다.

 

다시 말해 Long-Running 브랜치가 여러 개일 필요가 없어

정말 유용한 방식입니다.

특히 규모가 크고 복잡한 프로젝트일수록

그 유용성이 반짝반짝 빛납니다.

(master 브랜치에 계속해서 merge하기 때문에, master branch는 Long-Running 합니다.)

 

 

topic branch

토픽 브랜치는 프로젝트 크기에 상관없이 유용합니다.

토픽 브랜치는 어떤 한 가지 주제나 작업을 위해 만든 짧은 호흡의 브랜치입니다.

 

앞서 보았듯 특정 이슈를 해결하기 위해 만든 iss53 브랜치나

hotfix 브랜치가 바로 토픽 브랜치입니다.

 

보통 주제별로 브랜치를 만들고, 각각은 독립돼 있기 때문에,

매우 쉽게 컨텍스트 사이를 옮겨 다닐 수 있습니다.

이렇게 묶음별로 나눠서 일하면

내용별로 검토하기에도, 테스트하기에도 더 편합니다.

각 작업을 하루든 한 달이든 유지하다가

master 브랜치에 Merge 할 시점이 되면 순서에 관계없이 그때 Merge 하면 됩니다.

 

 

예시

토픽 브랜치가 많다.

 

C1 커밋 상태에서, 특정 이슈를 해결하기 위해 iss91 브랜치를 만들었습니다.

 

iss91 브랜치의 C4 커밋 상태에서 다른 방법을 시도해보기 위해 iss91v2 (버전 2) 브랜치를 또 만들어 시도중입니다.

 

이후 C10 커밋에서, 기발하고 새로운 아이디어를 실험해보기 위해 dumbidea라는 브랜치를 만들어 관리중입니다.

 

이 와중에, 운영단계에 들어간 production 브랜치인 master 브랜치도 계속 유지하고 있습니다.

 

이런 상태의 커밋 히스토리가 바로 위와 같은 그림입니다.

 

이 상태에서, dumbidea 브랜치의 아이디어가 긍정적인 평가를 얻어

master와 merge하는 것을 승인 받았습니다.

 

이 때의 merge는 Fast forward 방식으로 진행됩니다.

 

또한,

iss91 에 대해 v2 브랜치의 해결책이 더 낫다는 결정을 내렸다고 쳐봅시다.

때문에 iss91 브랜치는 버리고, iss91v2 브랜치를 master에 merge합니다.

이 때의 merge는 3-way merge 방식입니다.

 

그 결과가 아래와 같습니다.

dumbidea 와 iss91v2 브랜치를 Merge 하고 난 후의 모습, C14 는 3-way merge로 인해 생긴 커밋이다.

 

 

주의사항

지금까지 한 작업은 전부 로컬에서만 처리한다는 것을 꼭 기억해야 합니다.

로컬 저장소에서만 브랜치를 만들고 Merge 했으며 원격 서버와 통신을 주고받는 일은 없었습니다.

 

 

 

 

[다음 포스트]

[Git] 협업 필수, 원격 브랜치(remote branch)

 

 

 

 

 

Ref.

Git - 브랜치 워크플로