[Git] git 브랜치 활용 및 git flow 실습

1. Git 브랜치 활용 전략

---

브랜치가 왜 필요할까?

필요한 이유는 소프트웨어의 특성에서 비롯된다. 소프트웨어 개발에 가장 중요한 요인은 변경점 발생이다. 예를 들어, 소프트웨어를 개발하다가 고객의 요구사항이 변경되어서 특정 기능을 수정해야 하는 경우가 빈번하게 발생한다. 또는 이미 개발이 되어 릴리즈 된 상태에서 고객이 해당 제품을 사용하다가 문제점이 발생했을 때 해결하는 과정에서 변경점은 발생하게 된다.

 

소프트웨어에 대한 변경은 개발 진행중에 또는 개발이 완료되어 사용 중인 제품에서 발생하는 문제점을 해결하거나 개선하기 위해 발생할 수 있다. 이러한 소프트웨어에서 빈번하게 발생하는 변경점을 관리하기 위해 가장 중요한 도구가 브랜치이다.

 

앞 장에서 브랜치 이해를 위한 실습을 진행했을 때 기준이 되는 master 브랜치에서 feature-login이라는 특정 브랜치를 만들어서 따로 개발을 했고, 변경점들을 master 브랜치에 병합을 했다. 그리고 issue라는 브랜치를 생성하여 issue를 해결하는 여러 커밋들을 생성하고 master 브랜치로 병합하는 실습을 진행했다.

즉, 브랜치가 필요한 이유는 소프트웨어의 변경점을 효율적으로 관리하기 위해 필요하다.

 

 

git을 이용한 브랜치 활용 방식은 개인/조직마다 다를 수 있다.

 

검은색은 master, 회색은 release 브랜치이다. 파란색, 주황색, 노란색 브랜치들은 경우에 따라 특정 feature를 개발하는 브랜치가 될 수 있고 개발자들이 개발하려는 별도의 공간인 브랜치 일 수 있다. 실제 소프트웨어를 개발할 때 변경점을 어떻게 관리할 것인지 당연히 개인/조직마다 다르게 될 것이다. 때문에 git을 이용한 브랜치 활용도 다를 수밖에 없다.

 

브랜치 활용 전략은 소스코드의 효율적인 관리를 위해 프로젝트의 모든 리스크를 최소화하는 방향으로 일관되고 생산적인 방식으로 조직에 맞게 프로세스화 시켜야 한다.

 

브랜치 활용 전략 모델

• feature 별 branch
• 개발자별 branch
• 스프린트 주기별 branch
  스크럼이란 프로젝트 관리를 위한 점진적인 개발 방법론 중 하나이다. 애자일 소프트웨어 개발 방법론 중 하나이다. 이 스크럼에서는 특정 개발 주기를 정해서 진행한다. 해당 개발 주기를 스프린트라고 한다.
• 사내 검증 단계별 branch
• 브랜치 활용 전략 모델(방법론) : GitFlow

가장 대표적인 브랜치 활용 전략 방법론은 GitFlow이다. GitFlow는 소프트웨어의 특징인 변경점을 반영하여 효율적으로 관리할 수 있을지 축약해놓은 일종의 프로세스이다. 기업에서는 이 GitFlow를 그대로 도입해서 사용하는 것이 아니라, GitFlow를 기반으로 조직의 특성에 맞게끔 일부는 변경하거나 점진적으로 개선하여 사용하는 경우가 많다.

 

 

 

2. GitFlow

---

GitFlow는 총 5개의 브랜치를 사용해서 변경점을 관리한다.

• master branch
• develop branch
• feature branch
• release branch
• hotfix branch

 

 

2-1. GitFlow 모델 - master

git에서 repository를 생성하고 초기화하고 특정 커밋을 생성하면 master라는 기본 브랜치가 생성된다. master는 git의 가장 기본 브랜치이다. 실제 GitFlow에서도 master 브랜치는 가장 기본이 되는 브랜치이다.

• 실제 고객에게 릴리즈되는 브랜치(production)
• 모든 변경사항은 결국 master로 최종 반영되어야 함

 

 

master브랜치를 기준으로 develop브랜치를 생성하여 develop브랜치에서 기능이 어느 정도 개발이 되고 고객에게 릴리즈 되는 수준이 되면 master브랜치로 merge 해야 고객에게 변경점이 적용된 소프트웨어가 전달될 수 있다.

 

2-2. GitFlow모델 - develop

• 실제 개발의 중심이 되는 브랜치
  master 브랜치에서 모든 개발이 진행 되는 것이 아니라
  master 브랜치를 기준으로 develop 브랜치를 생성하여
  기능을 개발하고 이슈도 해결하고 수정하는 모든 작업을 한다.
• 즉, 모든 기능이 추가되고 버그가 수정되고,
  고객에게 배포 가능한 수준이 되면
  develop의 내용은 master에 최종 반영 되어야 한다.

 

2-3. GitFlow모델 - feature

• 기능을 개발하는 브랜치
  일반적으로 develop브랜치가 개발 중심이 된다.
  develop브랜치에서 개발을 하다가 큰 단위의 기능을 개발한다면
  feature 브랜치를 생성하여 개발을 진행한다.
• develop 브랜치로부터 분기
• 기능 개발이 완료되거나 스프린트 주기가 종료되면
  develop브랜치로 merge 후 브랜치를 삭제한다.

 

 

2-4. GitFlow 모델 - release

• 배포를 준비(검증, 이슈 수정 등)하는 브랜치
• 배포 가능한 상태가 되면 master 브랜치로 병합
• release 브랜치에서 기능 점검시 발견한 이슈에 대한
  수정사항은 반드시 develop에 병합해야함.
• 배포 준비가 완료되면, 최종 master로 병합하고 tag를 명시해야 함.

 

 

2-5. GitFlow 모델 - hotfixs

• 배포한 버전에서 긴급하게 수정이 필요한 장애 및 버그 발생 시 대응하는 브랜치
• hotfixs는 master로부터 분기되며,
  이슈가 수정되면 수정 사항은 master, develop브랜치에 최종 반영되어야 함.

 

 

 

 

3. GitFlow 실습

---

$git flow init <- 초기화

• default로 enter 입력하여 초기화.
• git flow init을 진행하면 master브랜치와 develop브랜치가 생성되고
  develop브랜치로 cehckout 됨.

 

$git flow feature start [개발할 기능명 또는 이름 등] <- 기능 개발

특정 기능을 개발할 때 사용

 

현재 브랜치가 feature/login 브랜치로 checkout

 

login 기능을 개발한다고 가정하고, 임의의 커밋을 생성.

• $vi LoginService.java
  write code 1 저장
• $git add LoginService.java
• $git commit -m "Commit#1 on feature/login branch"
• $git log

 

 

$git flow feature finish [개발할 기능된 또는 이름] <- 기능 개발 완료

1. feature 브랜치 -> develop 브랜치로 merge
2. feature 브랜치 삭제
3. develop 브랜치로 이동

Summary of actions 부분에서 해당 명령어의 결과가 요약되어 있다.

• feautre/login 브랜치가 develop브랜치로 merge.
• feature/login 브랜치가 삭제.
• develop 브랜치로 checkout

 

 

두 번째 커밋 생성

• $vi MainService.java
  write code 2 저장
• $git add MainService.java
• $git commit -m "Commit#2 on develop branch"
• $git log

 

 

$git flow release start [버전명] <- 릴리즈 시작

 

$git flow release finish [버전명] <- 릴리즈 종료

릴리즈 브랜치에서는 고객에게 배포하기 위한 버전을 검증하면서 발생하는 여러 가지 이슈를 수정해서 반영한다.

각각의 수정사항들이 쌓이다 보면 master 브랜치로 보내서 고객에게 릴리즈하겠다는 의사결정을 하게 된다.

해당 시점에 릴리즈 브랜치에 반영되었던 모든 변경점들은 develop브랜치에도 반영되어야 하고 master브랜치에도 반영되고 tag까지 되어야 한다.

 

• $git flow relase finish 1.0

 

• 명령어를 입력하면 merge 커밋이 자동으로 생성된다.
• release/1.0 브랜치를 master브랜치에 merge 한다.

 

• 커밋을 저장하면 태그를 입력하는 창이 나타난다
  annotated 태그는 메시지를 입력해야 한다.
  complete release 1.0 입력.

 

• 태그를 저장하면 커밋을 입력하는 창이 나타난다.
  이 커밋은 release브랜치에서 develop브랜치로 merge 하는 커밋이다.

 

릴리즈 종료 -> 다음과 같은 화면이 나타난다.

 

마지막 작업을 release 브랜치에서 했었다.

$git flow release finish [버전명] 명령어를 실행하면 현재 브랜치가 develop 브랜치가 된다.

• $git log --oneline
• $git show 1.0

 

 

$git flow hotfix start [태그명 등] <- 긴급 이슈 발생 시

이미 고객에게 릴리즈 된 소프트웨어에서 긴급하게 수정되어야 할, 반드시 수정되어야 할 이슈가 발생했을 때 hotfix라는 브랜치를 이용한다. master브랜치에서 hotfix 브랜치가 생성된다. hotfix 브랜치에서 이슈를 해결하고 master 브랜치와 develop브랜치에 최종 반영된다. master브랜치에 주요한 버그가 수정이 되었다는 태그가 생성이 되어야 한다.

 

• $git flow hotfix start issue#1
• $vi MainService.java
  hotfix code 1 on hotfix branch 저장
• $git add MainService.java
• $git commit -m "hotfix commit#1 on hotfix branch"

 

 

$git flow hotfix finish issue#1 <- 긴급 이슈 해결

hotfix 브랜치에서 이슈를 해결했다고 가정하고 hotfix를 종료하는 과정을 진행한다.

• $git flow hotfix finish issue#1

• 위 명령어를 입력하면 master브랜치로 커밋하는 메시지를 입력하는 창이 나타난다.

 

• 별도의 수정 없이 저장한다.
• 다음으로 태그 메시지를 입력하는 화면이 나온다.

 

• master브랜치로 태그를 저장하면 한 개의 커밋이 더 발생한다.
  이 커밋은 issue#1에 해당하는 내용을 develop에 반영하겠다는 merge 커밋 메시지이다.
  별도의 수정 없이 저장한다.

 

• 이로서 긴급 이슈가 해결되었고 hotfix 브랜치에서 develop 브랜치로 돌아온 것을 확인할 수 있다.