깃 브랜치 이름 규칙과 전략

깃을 사용할 때는 브랜치를 통해 각 기능들을 구분하여 다른 공간에서 개발하게 된다.

그런데 말로만 기능들을 구분한다 하면 어떻게 구분해야 할지 헷갈리는데, 큰 틀은 다음과 같다.

 

- 기능 개발: feature/{기능명} (feature/login, feature/post, feature/mypage 등...)

- 출시 준비: release/{버전명} (release/1.0, release/1.1, release/2.0 등...)

- 긴급 수정: hotfix/{버전명} (hotfix/1.0, hotfix/1.1, hotfix/2.0 등...)

 

 

실제로 브랜치가 어떻게 작동되는지 알아보자.

먼저 git branch 명령어를 통해 두 개의 브랜치들을 만들었다.

 

 

이후 feature/login 브랜치로 이동하여 test.txt를 편집한다.

 

 

git add 와 git commit 을 통해 커밋을 완료하였다.

 

 

커밋을 완료한 뒤 feature/post로 브랜치를 변경하였다.

이후 test.txt를 확인하면 feature/login에서 편집한 내용이 반영되지 않은 모습을 확인할 수 있다.

 

즉, 브랜치를 통해 각 기능별로 병렬적으로 개발이 가능한 것이다.

이제 feature/post에서 작업한 내용을 깃허브 홈페이지에 push해보자.

 

 

현재 깃허브에는 main 브랜치만 존재하는 상태이다.

 

 

 

feature/login 브랜치가 깃허브에 잘 올라온 모습을 확인할 수 있다.

 

이렇게 편리하고 체계적인 브랜치 기능은 다양한 전략을 통해 활용된다.

전략은 크게 두 가지로 분류되는데 fast-forward와 3ways로 분류할 수 있다.

 

fast-forward 전략

fast-forward 전략을 그림과 함께 보면 다음과 같다.

A 브랜치에서 B 브랜치를 생성한 시점부터

A 브랜치에는 아무런 추가 구현을 하지 않고 B 브랜치에만 추가 구현한 뒤 

A 브랜치에 B 브랜치를 붙이면 되는 전략이다.

 

3-way 전략

3-way 전략을 그림과 함께 보면 다음과 같다.

A 브랜치에서 B 브랜치를 생성하고

A, B 브랜치에 추가 구현을 완료한 뒤

A, B 브랜치를 합쳐 A 브랜치와 B 브랜치를 서로 비교하여 바뀐 것을 정리하며 합치는 전략이다.

 

실제로는 둘 중 하나의 전략만을 사용하는 것이 아니라, fast-forward와 3-way 전략 모두 적절히 활용하여 사용한다.