이전 포스트에서 Git은 '로컬에서 혼자 사용할 수도 있고, 서버에 올리면 팀원들과 병렬로 사용할 수도 있다'고 하였다. 이때 사용되는특정 기준 커밋에서 줄기를 나누어 작업할 수 있는 기능을 브랜치라고 한다.
브랜치, 즉 작업 환경 변경은 checkout을 통해 수행되며, 이 동작을 스위치라고 표현한다. 이때 내가 어떤 브랜치 또는 커밋을 가리키고 있는지 알 수 있는 특수한 포인터를 HEAD라고 한다.
이 브랜치는 목적에 따라 다양한 방법으로 활용할 수 있는데, 대표적인 전략으로 git flow, github flow가 존재한다.
1. Git Flow
구성요소
- Master(Main): 출시 가능한 완성된 브랜치
- Develop: 개발이 완료된 브랜치
- Feature: 각 기능을 개발하는 브랜치
- Release: 개발이 완료되어 출시를 준비하는 브랜치
- Hotfix: 배포된 버전에서 발생한 버그를 수정하는 브랜치
예를 들어, 카카오톡 앱 개발을 하는 상황의 Git Flow는 다음과 같다.
먼저 개발을 수행하기 위한 develop 브랜치를 생성한다. 카카오톡 앱을 구성하는 기능을 개발하기 위해 채팅 기능을 개발하는 [feature/chat], 프로필 기능을 개발하는 [feature/profile] 등의 feature 브랜치를 생성한다. 각각의 feature 브랜치에서 기능 구현이 완료되면, develop 브랜치에 병합한다. 모든 기능이 구현되고, 출시 가능한 완성된 코드가 develop 브랜치에 모이게 되면 이를 master에 올리기 위해 release 브랜치에 임시로 저장하고, 최종적으로 master에 업로드한다. 배포된 1.0 master 버전에서 버그가 발생하면, hotfix 브랜치에서 문제점을 빠르게 수정하고, 수정안을 다시 master에 추가하여 새로운 버전인 1.1을 배포한다.
하지만 보다시피 Git Flow의 구조는 꽤 복잡하다. 앱 어플리케이션과 같이 버전 관리가 명시적으로 필요하다면 적합한 방식이지만, 웹 어플리케이션의 경우 불필요하다. 웹 어플리케이션은 사용자가 다운 받아 이용하는 게 아니고, 브라우저로 접속하여 이용한다. 단일 버전만 제공되고, 사용자가 버전 정보를 알 길도 없다. 또한, 최근에는 웹이 하루에도 몇 번씩 release 되기 때문에 이걸 전부 표기하고 적용하는 것이 어렵다. Git Flow보다 좀 더 단순한 방법으로, GitHub Flow가 있다.
2. GitHub Flow
구성요소
- Master(Main): 출시 가능한 완성된 브랜치
- Feature: 각 기능을 개발하는 브랜치
위에서 언급했듯, GitHub Flow는 Git Flow보다 단순한 구조를 가지고 있으며, 빠른 배포를 목적으로 한다.
각각 분담한 기능 업무에 맞게 [feature/브랜치명]의 feature 브랜치에서 작업을 하면, feature 브랜치의 코드와 master의 코드가 달라지게 되고, 작업 완료된 코드를 master에 데려오는 작업이 필요하다. 이 과정에서 팀원들과 코드 리뷰가 이루어지기도 한다.
이후 만약 first.md를 수정하고 commit과 push를 진행하면, 원격 저장소에 있는 것까지 가져올 수 있게 된다.
다시 main 브랜치로 스위치하여, 장바구니 기능을 구현하기 위한 feature/cart 브랜치를 생성 후 체크아웃 하였다.
1. Merge
각자의 브랜치에서 개발이 완료되면, 작업물들을 최종 완성본인 Main 브랜치에 합쳐야 한다. 이를 Merge(병합)이라고 한다. Merge에도 2가지 방법이 있는데, Fast Forward(빨리 감기)와 Merge Commit(병합 커밋)이다. 빨리 감기는 Main으로부터 파일을 가져와서 작업한 두 개의 브랜치 중 한 개의 브랜치만 수정되었을 경우, 단순히 가리키는 위치를 변경하는 것이다. 병합 커밋은 Main으로부터 파일을 가져와서 작업한 두 개의 브랜치가 각각 겹치는 영역 없이 다르게 동시에 수정했을 경우, 단순히 두 내용을 합치는 것이다. 다만, 이 영역이 겹친다면 Conflict(충돌)이 발생한다. Conflict가 발생하면 코드를 직접 살펴보고 수정하는 과정을 거쳐야 하기 때문에, 이를 피하기 위해 사전에 각자 사용할 파일과 브랜치의 영역을 세부적으로 분담할 필요가 있다.
2. Pull Request
우리는 GitHub으로 협업을 한다. 공동 작업물에 한 사람이 다른 사람의 검토 없이 자신의 작업물을 최종 완성본인 Main 브랜치로 업데이트 해버리면 곤란할 것이다. 따라서 작업을 마쳤다는 것을 알리고, 팀원들에게 코드 리뷰를 받기 위한 Pull Request를 해야 한다.
3. Tag & Release
특정 커밋에 태그를 달 수도 있다. 태그의 내용은 대개 버전 정보를 포함한다. 이 태그를 기반으로 Release를 만들 수 있고, 오픈 소스로 제공하는 레포지토리에서 잘 활용되는 기능이다.
