[실무자가 알려주는 Git 활용한 프로젝트 관리] Git 브랜치의 이해와 활용

코드프레소 Java 웹 개발 체험단 활동 중

코드프레소 이러닝 강의 수강 - 실무자가 알려주는 Git 활용한 프로젝트 관리

코드프레소 URL: https://www.codepresso.kr/

 

1. Git 브랜치

브랜치 (branch)

본래의 소스코드로 부터 파생한 독립적인 작업 공간

최신 커밋을 가리키는 일종의 포인터이다.

매우 가볍다.

생성, 이동, 병합 (merge)이 매우 쉽다.

 

병렬적으로 작업하다 보면 흐름이 동기적으로 진행되지 않기 때문에 이를 관리할 수 있는 도구가 필요하다. Git에선 브랜치가 해당 기능을 수행한다. 브랜치의 개념부터 알아보자.

HEAD

현재 브랜치를 가리키는 일종의 포인터

현재 브랜치의 마지막 커밋에 대한 스냅샷

 

브랜치를 분기하게 되면 해당 브랜치 이름으로 HEAD에서 갈라지는 흐름이 생기게 된다. 목적에 따라 분리할 수 있으며 대부분 관리 전략을 통해 체계적으로 관리한다.

이 상태에서 커밋을 하면 main 브랜치에 반영되지 않고, 분기된 브랜치의 흐름의 맨 마지막에 생긴다. 또한 개발이 완료되어 브랜치의 내용을 병합할 수도 있다.

master 브랜치는 2.6버전 이전의 기본 브랜치 이름이다.

병합할 때 다른 사람의 작업 내용과 겹치는 부분이 발생할 수 있다. 이를 충돌 (confilict)라 하는데, 이 때는 어떤 사람의 내용을 병합할 지 프로그램 입장에서는 알지 못한다. 따라서 수작업으로 병합해주어야 한다.

A~B의 내용이 HEAD의 내용이고 B~C까지의 내용이 작업 브랜치의 내용이다.

개발자는 에디터에서 소스코드를 보고 어느 브랜치의 작업을 반영할 지 결정하게 된다.

브랜치는 태그를 지정할 수도 있다. 의미적으로 중요한 시점일 때 태그를 달아 가시적으로 확인할 수 있다.

 

의미있는 시점이란?

- 1차 목표 기능 개발 완료되었을 때,

- 매우 중요한 이슈가 해결되었을 때,

- 기능 개발 완료 및 테스트까지 모두 완료하여 통과하였을 때,

- 고객에게 소프트웨어를 배포할 때 등등

 

태그 활용 전략

Git을 이용한 태그 생성 시점은 조직마다 다를 수 있다.

- 태그 생성 시점?

- 태그명 규칙?

- 태그 메시지 규칙?

중요한 것은 소스코드의 효율적인 관리를 위해 태그 생성 시점과 방법에 대해서 일관성 있는 규칙(프로세스0을 정해 프로젝트 팀원 모두가 준수할 수 있도록 정책화 해야 한다.

 

앞서 git 브랜치는 조직마다 전략이 다를 수 있다 했다. 대중적으로 사용하는 모델인 Git Flow를 많이 사용한다. 각 브랜치의 이름과 역할을 알아보자.

 

GitFlow 모델

아래 브랜치를 활용하여 변경점 관리하는 모델

- master branch

- develop branch

- feature branch

- release branch

- hotfix branch

GitFlow 모델 - master

실제 고객에게 릴리즈되는 브랜치 (production)

모든 변경사항은 결국 master로 최종 반영되어야 함

GitFlow 모델 - develop

실제 개발의 중심이 되는 브랜치

즉, 모든 기능이 추가되고 버그가 수정되고, 고객에게 배포 가능한 수준이 되면 develop의 내용은 master에 최종 반영되어야 함

다음 배포할 기능 개발하는 브랜치

GitFlow 모델 - feature

기능을 개발하는 브랜치

develop 브랜치로부터 분기되어 사용됨

- feature 브랜치의 단위? 기능, 스프린트 주기 등

기능 개발이 완료되거나 스프린트 주기가 종료되면 develop 브랜치로 내용 merge 후 브랜치 삭제됨

GitFlow 모델 - release

배포를 준비(검증, 이슈 수정 등)하는 브랜치

배포 가능한 상태가 되면 master 브랜치로 병합

release 브랜치에서 기능 점검시 발견한 이슈에 대한 수정사항은 반드시 develop에 병합해야 함

배포 준비가 완료되면 최종 master로 병합하고 tag를 명시해야 함

GitFlow 모델 - hotfixs

배포한 버전에서 긴급하게 수정이 필요한 장애 및 버그 발생시 대응하는 브랜치

hotfixs는 master로부터 분기되며, 이슈가 수정되면 수정 사항은 master, develop 브랜치에 최종 반영되어야 함