Git 방법론 Git Flow 에 대하여

우리는 코드를 관리하기 위해서 Git을 사용합니다.

인터넷에서 Git은 다음과 같이 정의됩니다.

Git이란 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템, 또는 그런 명령어.

맞는 말입니다. 특히나 요즘 개발자라면 모르는 사람이 없는 Github 뿐만 아니라 BitBucket, Gitlab 등이 우리가 깃을 좀 더 다루기 수월하게, 그리고 배포를 좀 더 쉽게 만들어주고 있죠.

서론은 여기까지 하고, 이 글의 주제인 Git-Flow란 무엇이고, 어떻게 사용하는가에 따라서 알아봅시다.

그래서 Git-Flow가 뭔데?

Git은 기본적으로 여러 명의 사용자가 협업하기 위한 시스템입니다. Git-Flow는 그 시스템 내에 존재하는 방법론입니다. 여러 전략 중의 하나일 뿐이죠. Git이 활성화 되는 시기에 Vincent Driessen 이라는 사람이 고안해냈다고 합니다. 기본적으로 이 방법론은 다음과 같은 브랜치를 들고갑니다.

• master (또는 main)
• develop
• feature
• release
• hotfix

어찌보면, 브랜치명들이 정말 익숙합니다. Git-Flow를 제대로 모르는 사람들도 명칭 자체는 익숙한걸 보니, Git-Flow으로부터 많은 방법론들이 전파되었다고 생각할 수도 있겠군요.

위 브랜치명들을 보시면 아시다시피, 직관적입니다. 그리고 협업을 하기에 정말 효율적인 기능들을 가지고 있군요. 이해가 안 가시면, 사진과 함께 살펴봅시다.

Git-Flow를 설명할 때, 그냥 이 사진이 보통 쓰입니다. 그만큼 이해하기에 정말 적합한 사진이죠. 먼저, 위 방법론에서 main 과 develop 브랜치는 베이스로 항상 존재합니다. 정말 중요한 존재죠.

mater 브랜치라고 부르지 않는 이유는 다들 아시죠?

main 은 말그대로 배포용 브랜치입니다. 실제 서비스에 배포될 코드를 가지고 있죠. develop 은 말 그대로 개발용입니다. 위에서 이 두 브랜치가 가장 중요하다고 말했었죠. 전자는 말할 것도 없지만, develop 은 왜 중요할까요? 바로, 우리가 개발하는 거의 모든 작업들이 합쳐지는 곳이기 때문이죠.

그렇기때문에, 가장 많이 충돌이 나는 곳이구요. 만약 develop 브랜치에서 2명이서 작업하다가 conflict 난다면? 3명이서 난다면..? 5명...? 정말 끔찍하군요. 이제 Git-Flow를 사용할 차례입니다.

기본적으로 develop 브랜치에서부터 시작됩니다. 자, 우리 개발자들은 열심히 개발을 해야겠죠? 하지만 그 전에, 충돌의 최소화와 기능의 책임화를 극대화시키기 위해서 우리는 feature 브랜치를 사용할 겁니다. 이 브랜치가 만들어지는 조건은 아마 여러가지가 있겠죠? 네, 열심히 개발을 해서 feature 에서 develop 으로 코드를 합칠겁니다.

• feature ⇒ develop
  • 웬만해서는 Squash 를 사용하고, 완료된 feature 브랜치를 제거해줍니다.
  • 제거할 수 없는 상황이라면 Rebase 를 하고, 작업을 지속해줍니다.

이렇게 기능들이 develop 브랜치에 보이고 있습니다. 이제 테스트를 거치고 싶군요! 또는 QA를 진행하고 싶습니다. 이 때, 저희는 바빠서 계속 develop 브랜치에 개발을 진행해야 해요. 어떻게 할까요?

이럴 때 사용하는 것이 release 브랜치입니다.

• develop ⇒ release
  • 👨‍🎓: QA가 완료될 때까지 해당 릴리즈를 수정할께요!
  • 👩🏻‍🌾: 수정한 코드는 develop 에 함께 최신화 진행하겠습니다.
  • 👩🏻‍🌾: 테스트서버는 release 브랜치를 바라봐 주시면 됩니다~

이제 QA가 완료되고, 배포 승인이 떨어졌습니다! 배포를 한 번 진행해볼까요?

• release ⇒ main
  • Squash 를 사용하여 main 브랜치로 머지하고, 브랜치를 제거해줍니다.

앗! 갑작스럽게 수정해야할 문제가 있어요, 핫픽스를 사용할 차례입니다.
보통 긴급수정은 이미 배포한 실서비스에서 빠르게 문제 처리해야할 상황입니다. 그렇기에, 이번에는 develop 브랜치가 아닌, main 브랜치에서 hotfix 브랜치를 만들어줍니다. 그리고 한 번 문제를 수정해보도록 하죠.

• hotfix ⇒ main
  • 👩🏻‍🌾: 긴급수정 사항을 main 브랜치에 합치는거 당연한 일입니다.
  • 👩🏻‍🌾: 그치만, main 이 전부 일까요?
• hotfix → develop
  • 긴급 수정사항을 현재 개발 중인 develop 브랜치에도 머지해줍시다.

각 브랜치에 합칠 때에는 rebase를 해도 되고, merge를 해도 됩니다.

하하, 벌써 Git-Flow의 모든 것을 설명하였군요. 사실 여기서 말한 것들 외에도 실무에 적용하려면 여러가지 생각할거리가 많습니다. 예로 들어볼까요?

• 👨🏻‍💼: 코드가 충돌났을 때에는 어떻게 처리하나요?
• 👨🏻‍🏭: 이슈는 어떤 기준으로 관리하나요?
• 👷‍♀️: 개발자는 나 혼잔데, 이렇게까지 해야돼나요?

음.. 여러가지 문제점들이 존재하군요. 정말 복잡합니다.
정말 이게 편한가요? 꼭 필요한가요?? 저는 항상 이런 질문을 속으로 대답하려고 하고 있습니다. 어렵지만요 하하

그래서 편해?

솔직히 편하다고는 장담하지 못합니다. 당연히 혼자서 개발할 때 제일 편한건 main 브랜치 하나에서 개발하는 것이 가장 심플하죠. 그렇다면 왜 이렇게 복잡한(?) 구조로 코드를 관리하나요?

확실히 Git-Flow는 단일 개발보다, 다수의 개발자들이 사용하기에 적합한 방법론입니다. Git의 개념과 맞게 작업을 조율하기 쉽기때문이죠. 다수가 하나의 어플리케이션을 개발할 때, 끊김없이 지속될 수 있는 모델이기도 하구요. 그렇다고 완벽한 방법은 아닙니다. 언제든지 개발 상황에 맞게 전략을 재편성하는 것이 최고의 방법이죠.

저 같은 경우에는 Git-Flow를 택했지만, 완전하게 받아들이지는 않았습니다. 1명 또는 2명이서 진행하기에는 살짝 번거로운 감이 있었기 때문에, 몇 가지는 skip했었죠. 또한 저는 Github에 존재하는 Pull Request 기능을 사용하려고 하니 그 중에서 Rebase and Merge 가 있는데, 이거랑 Rebase 랑은 또 다르더라구요 허허... 최대한 개발자들이 편할 수 있도록 지금도 생각 중입니다.

브랜치 전략은 팀원과 상의해라

결국 브랜치 전략은 협업 전략입니다. 그렇기에 아무리 혼자 열심히 만들어도 상대방이 써주질 않으면 그만입니다. 같이 상의해보세요. 그리고, 전략을 수정해나가세요.