[Git] Git 좀 세울줄 아는 남자-2

https://ch4njun.tistory.com/242

[Git] Git 좀 세울줄 아는 남자-1

이번 포스팅에서는 첫 번째 포스팅에 이어서 Git Branching Model 에 대해서 설명하려고 한다. 기본적으로 Git 에 존재하는 명령어는 안다는 전제하에 포스팅을 작성할 것이기 때문에 반드시 첫 번째 포스팅부터 보는 것을 추천한다.

Git Branching Model

---

우선 늘 그렇듯이 왜 Git Branching Model 이 왜 필요한지에 대해서 이야기해보자.

 

Git 은 매우 복잡하고 Work Flow(Git 을 이용하는데 있어서)에 아무런 제약이 없다. 이렇게 정형화 되어있는 사용방법이 없기 때문에 모두가 다르게 사용하고 협업하는데 있어서 불편함이 발생할 수 있다.

 

따라서 조직에 맞는 Work Flow 를 정의해서 모두 이에 맞춰 Git 을 사용해 협업을 진행해야 한다. 조직에 따라 그에 맞는 Work Flow 를 구성하면 개발 효율이 상승하기 때문에 조직의 환경 등을 고려해 정의해야 한다.

 

이러한 목표를 위해 잘 알려진 Git Branching Model 에 대해서 알아두는 것이 좋다. 결국 목표는 어떠한 상황(조직의 환경)에서 어떠한 Git Branching Model 을 사용하는 것이 좋은지 판단해야 하기 때문에 많은 개발자들이 사용하는 신뢰할 수 있는 Git Branching Model 을 알아두는 것이 중요하다.

 

대부분의 기업에서도 이렇게 잘 알려진 Git Branching Model 을 사용하거나 약간 변형해서 사용한다고 한다. 이번 포스팅에서 총 3가지의 Git Branching Model 을 소개하는데 대부분 여기서 크게 벗어나지 않는다고 한다.

Git Flow

---

 

Git Flow 는 2010년도에 발표된 가장 보편화된 Git Branching Model 이다. 발표 원문은 아래 링크를 통해서 확인할 수 있다.

http://nvie.com/posts/a-successful-git-branching-model/

A successful Git branching model

 

실제로 배달의 민족에서도 Git Flow 를 변형해 사용하고 있고 다양한 기업에서도 많이 사용하고 있는 Git Branching Model 이다. 이러한 Git Flow 는 어떤 기업에 도입해도 될 정도로 범용적으로 사용할 수 있다. 하지만, 그만큼 복잡하기 때문에(Branch 가 많아짐) 큰 프로젝트에 사용하기엔 적합하지 않다고 한다.

https://techblog.woowahan.com/2553/

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

 

간단하게 Git Flow 발표에서 사용된 그림 한장을 통해서 Git Flow 에 대해서 간단하게 설명해보려고 한다. 간단한 흐름에 대해서만 설명하려고 하고 심화된 내용은 다루지 않는다. 자세한 내용이 궁금하다면 위에 첨부한 몇 가지 자료들을 참고하면 된다.

위 그림에서 등장하는 Branch 의 종류와 흐름은 다음과 같다.

• Feature Branch : 개발자가 사용하는 Branch 이다. (개발자가 자신만의 개발 Branch 를 만들 때 모두 여기에 해당)
   - Feature Branch 는 반드시 Develop Branch 로부터 쪼개져 나와야 하고, 다시 Develop Branch 로 Merge 되어야 한다.
  
  
• Develop Branch : 성공적으로 코딩된 모든 소스코드가 존재하는 Branch 이다. 중앙 저장소라고 생각하면 된다. 해당 Branch 에 소스코드가 들어오면 개발이 종료되었다고 판단한다.
  
  
• Release Branch : 일반적으로 QA 가 진행되는 동안 위치하는 Branch 이다. 통합 테스트 혹은 최종 테스트와 같은 작업이 수행된다.
   - 반드시 Develop Branch 로부터 쪼개져 나와야 하고, 버그를 수정한 경우 Develop Branch 로 Merge 되어야 한다. 최종적으로 테스트를 마친 경우 Develop Branch 와 Master(main) Branch 로 Merge 되어야 한다.
  
  
• Hotfix Branch : 운영중에 Master(main) Branch 에서 발견된 에러들을 수정하기 위한 Branch 이다.
   - Master(main) Branch 에서 쪼개져 나와야 하고, 버그를 수정한 경우 Develop Branch 와 Master(main) Branch 로 Merge 되어야 한다.
  
  
• Master(main) Branch : 무조건 고객(클라이언트)에게 배포되는 소스코드가 위치한 Branch 이다.
   - Release Branch 혹은 Hotfix Branch 로부터 쪼개져 나온다.

기본적인 흐름은 배달의 민족 블로그에서 소개된 내용을 인용한다.

처음에는 master와 develop 브랜치가 존재합니다. 물론 develop 브랜치는 master에서부터 시작된 브랜치입니다. develop 브랜치에서는 상시로 버그를 수정한 커밋들이 추가됩니다. 새로운 기능 추가 작업이 있는 경우 develop 브랜치에서 feature 브랜치를 생성합니다. feature 브랜치는 언제나 develop 브랜치에서부터 시작하게 됩니다. 기능 추가 작업이 완료되었다면 feature 브랜치는 develop 브랜치로 merge 됩니다. develop에 이번 버전에 포함되는 모든 기능이 merge 되었다면 QA를 하기 위해 develop 브랜치에서부터 release 브랜치를 생성합니다. QA를 진행하면서 발생한 버그들은 release 브랜치에 수정됩니다. QA를 무사히 통과했다면 release 브랜치를 master와 develop 브랜치로 merge 합니다. 마지막으로 출시된 master 브랜치에서 버전 태그를 추가합니다.

출처 : https://techblog.woowahan.com/2553/

 

Git Flow 의 단점은 앞서 말했듯이 Feature Branch 에 개발자가 많아짐에 따라서 Branch 의 수가 많아져 Git 이 복잡해질 수 있다는 점이다. 무엇이 옳다는 없지만 더 적합한 Work Flow 를 선택해야 한다.

Github Flow

---

Git Flow 는 그림만 보더라도 복잡한 것을 알 수 있다. Git Flow 에서는 배포 과정부터 QA, Hotfix, 배포 등 다양한 프로세스를 관리해주기 때문에 복잡할 수밖에 없다. 그에 따라서 좀 더 간단하게 나온 Work Flow 가 Github Flow 라고 생각하면 될 것 같다. 

Github Flow 는 쉽게 말해 master(main) Branch 만 엄격하게 관리하는 Work Flow 라고 생각하면 된다. 여기에는 당연히 제약사항이 존재하는데 바로 master(main) Branch 는 항상 배포 가능한 상태를 유지해야 한다는 것이다.

 

이러한 면에서 Git Flow 에서 Develop Branch 와 굉장히 유사하다. 하지만 Git Flow 에서 Develop Branch 와의 차이점은 Release Branch 즉, QA 과정을 별도의 Branch 로 분리하는지 여부이다.

 

한줄로 정리해 보면 "너가 개발하고 싶다면 원하는 대로 Branch 를 따서 개발을 해라. 하지만 master(main) Branch 에 해당 코드를 Merge 하고 싶다면 반드시 컴파일 및 배포 가능한 상태여야 한다" 이다.

 

 

추가로 Github Flow 에서는 Pull Request 를 권장한다.

• 너가 원하는대로 Merge 할 수 없어!! 너가 누군지알고..? 나쁜짓 하는 거면 어떡해!!
• 대신 Pull Request 를 남겨라. 즉, Merge 하고 싶다면 하고싶다고 요청을 보내라!!
  그러면 내가 확인, 검증하고 허락해줄게~

대충 이런 내용이다ㅎㅎ; Pull Requset 에 대한 자세한 내용은 따로 정리하는 것으로 하고 넘어간다!

GitLab Flow

---

GitLab Flow 는 Github Flow 가 너무 단순해서 개발환경이나 배포환경에 맞게 보완한 Git Branching Model 이다. GitLab 이라는 것은 소스코드 관리부터 배포까지 관리해주는 하나의 개발 툴 중에 하나이다. 즉, GitLab Flow 라는 것은 GitLab 시스템에서 사용하고 그에 맞는 Git Branching Model 이라고 생각하면 된다.

 

GitLab Flow 는 배포를 관리해야 하기 때문에 Github Flow 와 다르게 Production Branch 를 별도로 가지고 있다. 쉽게 말하면 Github Flow 의 장점을 가져오되 Production Branch 를 별도로 두고 배포를 관리한다고 생각하면 좋을듯 하다. 확장으로 master, pre-production, production 으로도 구성할 수 있다.

 

하지만 GitLab Flow 에서의 핵심은 이러한 Branch 가 아니라 Issue Tracker 와 연결해 사용한다는 것이다.

 

Issue Tracker 란?

'Login Bug Fix' 라는 Commit 메시지를 통해서 얻을 수 있는 정보는 그리 많지 않다. 어떠한 Bug 였는지 판단하기 어렵기 때문에 직접 코드를 분석하거나 하는 번거로움이 수반될 수 있다. 이러한 문제를 해결하기 위해 사용되는 것이 Issue Tracker 이다. 게시판 같은 형태로 Issue 를 '#1' 라는 제목으로 상세 정보를 저장하는 것이다.

그러면 Commit 메시지를 '#1 Login Bug Fix' 형태로 구성하고 #1 을 눌렀을 때 해당 Issue 로 Tracking 되도록 도와주는 도구가 Jira 와 같은 Issue Tracker 이다.

실제사례

---

실제 기업에서는 위에서 소개한 Git Flow, Github Flow, GitLab Flow 를 그대로 사용하거나 변형해서 사용한다. 그러면 실제 기업에서 사용하는 Git Branching Model 은 어떠한 특징이 있는지 살펴보자.

 

물론 기업마다 사용하는 Git Branching Model 은 다르고 정답은 존재하지 않는다. 해당 조직에 맞는 Work Flow 를 가지는 Git Branching Model 을 선택해 사용하는 것이 가장 좋다.

 

 

기본적으로 사용하는 도구는 Jira, Bitbucket 이다. Jira 를 통해서 Issue 를 관리하고 Bitbucket 을 사용해 Git Hosting 을 진행한다.

(이 두 개의 도구를 포함해 SourceTree 까지 총 3개의 도구는 모두 같은 회사에서 만들어 호환성이 좋다)

 

주요 Branch : work

(master 라는 Branch 는 약속된 Branch 이름으로 사용하기 때문에 work 라는 이름을 임의로 사용한다)

• 항상 컴파일 & 배포 가능한 상태를 유지해야 한다.
• Pull Request 를 통한 변경만 허용한다. (이 과정에서 Code Review 를 진행한다)
• 개발 완료된 모든 소스코드를 포함한다.

Develop, Master, Test 와 같은 Branch 명은 인프라팀과 약속해 사용하는 이름으로 이러한 기준을 두고 Jenkins 에서 Webhook 을 통해서 해당 Branch 의 Push 를 감지해 배포와 같은 이후 동작을 자동으로 수행하도록 구성한다. 이렇게 약속된 Branch 이름을 별도로 사용할 경우 Jenkins 가 감지해버리기 때문에 work 라는 Branch 이름을 사용하는 것이다.

 

 

work Branch 에 Merge 하기에 앞서 반드시 Rebase 를 통해 work Branch 의 꼭대기로 Branch 를 이동시킨다. 해당 과정에서 Squash 를 통해서 Commit 을 정리해야한다. Rebase 하는 과정에서 발생하는 Conflict(충돌)은 개발자 스스로 해결한다. (이렇게 Rebase 하는 이유는 앞선 첫 번째 포스팅을 참고하자)

 

이후 Pull Request 를 통해 Merge 를 요청한다. 팀원들의 Code Review 를 거친 후 승인이 떨어지면 Merge 를 수행해 work Branch 에 해당 코드를 합친다. 이렇게 함으로써 깔끔한(Depth가 1~2) Git Tree 를 유지할 수 있다. 

 

그리고 Develop, Test, Master Branch 를 상시로 두고 수정하는 것이 아니라 필요할 때(배포하려 할 때) Master Branch 를 쪼개고(쪼개면 Jenkins 에 감지되어 배포가 진행된다) 배포가 완료되고나면 다시 Master Branch 를 제거한다. 이렇게 하면 해당 Branch 는 단순한 점(하나의 Commit) 으로 존재하지만 이렇게 할 경우 소스코드의 History 를 관리할 수 없는데 Commit 에 추가할 수 있는 Tag 기능을 사용해 소스코드의 History 를 관리한다. 예를 들면 0.1 버전으로 배포했던 순간(Commit) 을 기록하기 위해 Tag 를 사용할 수 있다.

 

 

그럼 개발에 참여하는 개발자가 해당 Repository 에서 개발을 진행하고 싶을때 거치는 프로세스에 대해서 정리해보자.

1. Jira 에 Issue 를 생성한다.
   Issue 없는 개발은 없다. 한 글자라도 수정하고 싶다면 Issue 를 생성해야 한다.
2. Bitbucket 에 Issue 에 해당하는 Branch 를 생성한다.
   이 Branch 는 무조건 work Branch 에서 추가해야 한다.
3. Local 에 생성된 Branch 로 checkout 해서 개발을 수행한다.
4. 개발이 완료되면 Local Branch 를 work Branch 에 Rebase 한다.
   이 과정에서 Squash 를 통해 Commit 을 하나로 합친다. (최대한 적게 만든다)
   Rebase 과정에서 발생하는 Conflict 를 해결한다.
5. Rebase 완료한 Local Branch 를 Push 한다.
6. Bitbucket 에 해당 Branch 에 대한 Pull Request 를 작성한다.
7. 팀원들의 Code Review 를 진행한다.
   사전에 리뷰를 통과해야만 work Branch 에 Merge 가 가능하도록 Repository 설정을 변경해놓는다.
8. Code Review 를 마치면 work Branch 로 Merge 한다.

 

이러한 과정을 거치게 되면 Git Tree 을 이와같이 이상적인 모습으로 관리할 수 있다.

 

---

이러한 Git Branching Model 은 결국 하나의 기업 그 중에서도 하나의 개발 팀에서 사용하는 것이다. 이러한 Work Flow 에는 정답이 없기 때문에 항상 유연한 자세를 가지는 것이 좋다. 배달의 민족에서 사용하는 Git Flow 의 변형에 대해서도 자세히 읽어보면 좋을 것 같아 여러번 링크를 추가했지만 마지막으로 한 번 더 링크를 달며 포스팅을 마친다.

 

https://techblog.woowahan.com/2553/

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그