workflow에 따라 Git의 브랜치를 2개로 나누어 살펴볼 수 있다.
1. Long-Running 브랜치
: 개발을 진행하고 안정화할 브랜치를 추가 후 안정화가 됐을 때 '안정 브랜치(ex 'main 브랜치')'로 Merge할 브랜치
= 즉, main 브랜치에 merge되지 않은 활성화되어 있는 개발용 브랜치
- 이 브랜치는 언젠가 안정 상태가 되겠지만, 항상 안정 상태를 유지해야 하는 것이 아니며,
테스트를 거쳐서 안정적이라고 판단되면 main 브랜치에 Merge 한다▼
즉, 배포했거나 배포할 코드만 main 브랜치에 Merge 해서 안정 버전의 코드만 main 브랜치에 둔다.
- ex) 토픽 브랜치(앞서 살펴본 addQnA 브랜치 같은 짧은 호흡 브랜치)에도 적용할 수 있는데,
해당 토픽을 처리하고 테스트해서 버그도 없고 안정적이면 그때 Merge 한다.
- 히스토리 비교 이미지 : 그림 26. 안정적인 브랜치일수록 커밋 히스토리가 뒤쳐짐
| 개발 브랜치는 공격적으로 히스토리를 만들어 나아가고 VS 안정 브랜치는 이미 만든 히스토리를 뒤따르며 나아간다. |
- 장점 : 규모가 크고 복잡한 프로젝트일수록 유용하다
+) 프로젝트 규모가 크면 'proposed' 혹은 'pu'(proposed updates)라는 이름의 브랜치를 만들고
main 브랜치에 아직 Merge 할 준비가 되지 않은 것을 일단 여기에 Merge 시킨다.
요지는 여러 단계에 걸쳐서 안정화해 나아가면서 충분히 안정화가 됐을 때 안정 브랜치로 Merge 한다는 점이다.
2. 토픽 브랜치 (Topic branch)
: 어떤 한 가지 주제나 작업을 위해 만든 짧은 호흡의 브랜치
- 보통 주제별로 브랜치를 만들고 각각은 독립돼 있기 때문에 매우 쉽게 컨텍스트 사이를 옮겨 다닐 수 있다.
묶음별로 나눠서 일하면 내용별로 검토하기에도, 테스트하기에도 더 편하다.
- 각 작업을 하루든 한 달이든 유지하다가 main 브랜치에 Merge 할 시점이 되면 순서에 관계없이 그때 Merge 하면 된다.
- 장점 : 프로젝트 크기에 상관없이 유용하다.
+) 다른 버전 관리 시스템에서는 이런 브랜치를 본 적이 없을 것이다.
(∵ 다른 버전 관리 도구에서는 브랜치 생성에 큰 비용이 들기 때문에)
- ex) 앞서 사용한 addQnA나 hotfix 브랜치가 토픽 브랜치다.
Ex) 토픽 브랜치 (Topic branch) 생성 및 main 브랜치에 병합 예
ⓐ master 브랜치를 checkout 한 상태에서 어떤 작업을 한다고 가정한다.
ⓑ 한 이슈를 처리하기 위해서 iss91 브랜치를 만들고 해당 작업을 한다.
ⓒ 같은 이슈를 다른 방법으로 해결해보고 싶을 때도 있다.
iss91 브랜치의 C4 커밋내용까지를 포함한 상태인 iss91v2 브랜치를 만들고 다른 방법을 시도해 본다.
ⓓ 확신할 수 없는 아이디어를 적용해보기 위해 다시 master 브랜치로 되돌아가서 dumbidea 브랜치를 만든다.
(그 사이 master 브랜치에 이것저것 커밋되어 C10으로 진행됨)
ⓔ 지금까지 말했던 커밋 히스토리는 아래 그림 같다.
[그림 28. 토픽 브랜치가 많음] https://git-scm.com/book/en/v2/images/topic-branches-1.png
ⓕ 이슈를 처리했던 방법 중 두 번째 방법인 iss91v2 브랜치가 괜찮아서 적용하기로 결정했다.
ⓖ 그리고 아이디어를 확신할 수 없었던 dumbidea 브랜치를 같이 일하는 다른 개발자에게 보여줬더니 썩 괜찮다는 반응을 얻어
merge하기로 결정됐다!
ⓗ iss91 브랜치를 버리고(C5, C6 커밋도 함께), main 브랜치에 dumbidea , iss91v2 두 브랜치를 Merge 하면 아래 그림과 같이 된다.
[그림 29. dumbidea 와 iss91v2 브랜치를 Merge 하고 난 후의 모습]
https://git-scm.com/book/en/v2/images/topic-branches-2.png
"지금까지 한 작업은 전부 로컬에서만 처리한다는 것을 꼭 기억하자!!"
로컬 저장소에서만 브랜치를 만들고 Merge 했으며 서버와 통신을 주고받는 일은 없었다.
END!
스터디 도움 참조 블로그 (References)
| - 3.4 Git 브랜치 https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%9B%8C%ED%81%AC%ED%94%8C%EB%A1%9C - Long-Running 브랜치 https://medium.com/@_west_on/long-running-branches-8925a13001ef - git--distributed-even-if-your-workflow-isnt (Pro Git Book) https://git-scm.com/book/en/v2 |