Development/Story

[Git] 실제로 경험해 본 Git-Flow에 대한 정리

tyoon9781 2024. 12. 11. 22:58

 

 

* 목차

 - Intro

 - 필자가 사용한 Git-Flow 전략

 - Git-Flow 예시

   - Case1. Pull Request

   - Case2. Release

   - Case3. Hotfix

 - 마치며

 

 

 

Intro

git은 소스 코드 형상관리(Configuration Management) Tool입니다. git을 잘 사용한다면 개발자들 간의 협업을 용이하게 해주며 다양한 변경사항에 대한 추적 관리를 보다 쉽게 할 수 있습니다. git 자체는 Tool이므로 어떤 전략에 따라 사용하느냐, 어떤 git Repository Service를 사용하느냐에 따라 Process는 얼마든지 달라질 수 있습니다. 이런 방법을 선택하는데 있어서 가장 큰 요소는 Project의 크기입니다.

 

  • Project의 크기가 크다 : 복잡한 코드들의 추적성을 엄밀하게 따져야 하며 다양한 개발자들의 개발 산출물들이 나타나며 Merge가 반복적으로 일어날 것으로 예상됩니다. 그리고 개발 환경, QA 환경, Production 환경에 따라 엄격한 검증 절차가 필요합니다. 이런 경우 Git-Flow 전략이 필요합니다. 아래와 같은 Branch가 요구됩니다.
    • master
    • hotfix
    • release
    • develop
    • feature

  • Project의 크기가 작다 : 이런 경우 Project의 빠른 결과를 확인해야 합니다. 1명, 혹은 몇명 안되는 인원이 투입 되며, 엄밀한 검증보다 빠른 효과성을 봐야 합니다. 이런 경우 GitHub-Flow가 필요합니다. 아래와 같은 Branch가 요구됩니다.
    • master
    • feature

 

GitHub-Flow의 경우는 사실상 git tutorial 수준을 경험하신 분들이라면 누구든지 따라올 수 있는 난이도입니다. 이 글에서는 제가 실제로 사용했었던 Git-Flow 전략에 대해서 설명하도록 하겠습니다. 

 

 

 

필자가 사용한 Git-Flow

우선 실제 필자가 사용했던 branch 전략은 아래와 같습니다.

 

  1. User는 다음과 같이 설정한다.
    • Admin : Project 관리자. User Managing
    • Maintainer : Branch 관리자. Reviewer, Deploy Manager, Release Manager 등 역할이 있지만 혼용된다.
    • Developer : 개발자. 요구사항을 받아 개발한다.

  2. Branch는 다음과 같이 설정한다.
    • master
      • Pull Request는 staging, hotfix branch에서만 가능하다.
      • Release Manager는 Integration Test (통합 테스트) 후 master branch 반영 여부를 정한다.
      • Code가 update되면 운영환경에 반영된다.
      • update 시 v0.0.1 형태로 tagging한다.
    • staging (=release)
      • Pull Request는 develop branch에서만 가능하다.
      • Deploy Manager는 Release에 필요한 모든 요구사항이 적용되었는지 확인 후 staging branch 반영 여부를 정한다.
      • Code가 update되면 QA환경에 반영된다.
      • update시 v0.0.1-beta.1 형태로 tagging한다.
    • develop
      • Pull Request는 feature, hotfix branch에서만 가능하다.
      • Reviewer는 개발자들의 산출물을 review하고 develop branch 반영 여부를 정한다.
    • feature
      • 자유롭게 git push할 수 있다.
      • 개발자는 기능 단위로 develop branch에 Pull Request 할 수 있다.
      • 개발자는 추가된 기능에 대해 Unit test Code를 작성해야 한다.
      • feature branch name은 feature/{application} 과 같은 형태여야 한다.
    • hotfix
      • master branch source code의 심각한 issue가 발생하였으며 빠른 해결법을 알고 있을 때 사용하는 Branch.
      • hotfix branch에서 bug fix후 master branch에 직접 Pull Request 할 수 있다.
      • Reviewer, Deploy Manager, Release Manager 모두 Pull Request에 대해 Review해야 한다.
      • Review통과 후 master branch에 Merge가 되었으면 develop branch에도 동일하게 Pull Request 한다.
      • hotfix branch name은 hotfix/{bug}와 같은 형태여야 한다.

 

이런 전략으로 어떻게 운영했을까요? 그 예시를 그림으로 표현해 보았습니다.

 

 

 

Git-Flow 예시

그림으로 나타내면 다음과 같이 나타낼 수 있습니다.

git-flow의 local, remote branch를 나타낸 그림.

 

 

보통은 git-flow 전략을 설명하면 Remote Branch만 설명하는 경우가 많은데, Local Branch도 어떤 식으로 동작해서 git push, Pull Request가 일어나는지 알아야 이 전체적인 흐름을 제대로 이해할 수 있어 이런 그림을 그렸습니다.

 

이 그림에는 총 3가지 Case가 있습니다. 각각 설명하겠습니다.

 

 

 

Case1. Pull Request (PR)

Pull Request를 진행하는 Case이다.

 


개발은 개발자마다 각각 다른 기능들을 개발하기 때문에 이 코드들이 merge되었을 때 높은 품질을 유지하기 위해서는 develop에 merge하기 전 review를 잘 해야 합니다. 그렇기 때문에 git의 전략에서 제일 중요한 것은 Pull Request 관리입니다. 그래서 Case1에 대한 제목을 Pull Request라고 했습니다.

 

  1. develop branch를 fetch합니다.
  2. checkout -b로 feature/{application} branch를 만듭니다.
    • 누군가는 color를 개발합니다.
    • 누군가는 shape를 개발합니다.
  3. Color 개발을 시작합니다.
    1. 빨간색 color로 기능 개발이 완료 되었습니다. git commit, git push, PR를 수행 합니다.
    2. Reviewer가 PR을 처리합니다. Code 확인 결과 PR을 NG 처리합니다. NG와 관련된 Feedback도 전달합니다.
    3. Feedback을 적용하여 초록색 color로 기능 개발을 하고 git commit, git push, PR을 재 진행합니다.
    4. Reviewer가 PR을 처리합니다. 요구사항대로 반영된 것을 확인하고 Merge를 수행합니다.
    5. 이 시점에서 Develop Branch는 초록색 Color가 반영되었습니다.
  4. Shape 개발을 시작합니다.
    1. 정사각형 shape로 기능개발이 완료 되었습니다. git commit을 수행합니다.
    2. git push를 진행하기 전에 누군가 develop에 기능을 update했을 수도 있으므로 확인하기 위해 git pull origin develop을 수행합니다. 초록색 Color 기능이 있는 것을 확인했습니다.
    3. Merge 과정에서 충돌(Conflict)이 발생했습니다. 충돌을 해결(Conflict Resolution)한 후 git commit을 수행합니다. message에는 "[병합] 초록색 정사각형"이라 작성합니다.
    4. merge, commit이 완료되었으므로 git push, PR을 수행합니다.
    5. Reviewer가 PR을 처리합니다. 요구사항대로 반영된 것을 확인하고 Merge를 수행합니다.
    6. 이 시점에서 Develop Branch는 초록색 Color, 정사각형 Shape가 반영되었습니다.

 

 

누군가는 Pull Request를 실패했지만 그 feedback을 반영해서 제대로 된 code로 다시 작성했습니다. 이렇게 develop에 잘못된 code를 방어하기 위해서는 Reviewer의 역량과 Control이 중요합니다. 이 예제에서는 잘못된 구현으로 NG를 처리했지만 실제 NG 사례는 주로 Develop 병합 없이 git push를 진행하거나, 기능 사항에 대해 unit test code 누락으로 인한 NG 처리가 많았습니다.

 

 

 

 

Case2. Release

Deploy, Release를 진행하고 있다.

 

 

 

이 Case는 개발자들이 아닌 Maintainer들의 협업으로 이루어 집니다.

 

  1. 요구사항을 전달 받은 개발자들이 모두 개발을 마쳤습니다. 이 시점에서 Deploy Manager는 정말로 요구사항들이 개발 완료되었은지 점검합니다. 그리고 점검이 완료되었으면 Staging Branch에 pull request를 합니다.
  2. Reviewer들은 요구사항이 충족됨을 확인했으면 Merge를 수행합니다.
  3. git tag도 해당 commit에 적용합니다. tag 방식은 v0.0.1-beta.1로 합니다. 
  4. Release Manager는 Staging에 적용된 Service를 Integration Test(통합 Test)를 진행합니다. unit test 수준의 기능 단위 test가 아닌 UI/UX, 테스트 자동화로는 Cover할 수 없는 다양한 Test를 진행합니다.
  5. 운영환경과 매우 흡사한 QA환경에 적용된 Staging Branch source code의 검증이 완료되었습니다. PR을 Integration Test Pass Report와 함께 요청합니다.
  6. Reviewer들은 내용 확인 후 운영환경에 Merge를 적용합니다.

 

이 단계는 생각보다 수월하게 진행됩니다. 수월하게 진행된다고 해서 bug가 없는 코드라는 것은 아닙니다. 여기서 드러날 bug라면 사실 그 전에 대부분 드러나기 때문에 이 단계에서 문제를 찾는 것은 쉬운 일이 아닙니다. 보통은 운영에서 한참 후에 잠재된 bug가 드러나기 시작합니다. 이런 경우에는 어떻게 해결할 수 있을까요? feature branch부터 버그 수정사항을 반영해서 feature → develop → staging → master로 가면 되겠지만 deploy일정이 언제인지, release일정이 언제인지에 따라 그 기한을 맞출 수 없을정도로 빨리 해결해야 할 bug일지도 모릅니다. 이런 경우에 hotfix branch를 사용합니다.

 

 

 

 

 

Case3. Hotfix

hotfix 예시 Case이다.

 

 

Hotfix는 말 그대로 빠르게 고치는 것을 의미합니다. hotfix는 가끔 Windows hotfix라는 형태로 경험할 수 있는데 이는 windows update에서 보안 위험같은 빠르게 해결해야 하는 issue에 대해서 처리를 할 때 확인할 수 있는 update 형태입니다.

그림에서의 예시에서는 정사각형 shape가 보안문제를 일으킨다고 Report가 발행되었습니다. 그리고 해결책으로는 직사각형 Type이 필요하다고 합니다. 해결책도 알게 되었으니 빠르게 적용합시다.

 

  1. Bug Report가 발행되었습니다. 정사각형 Shape가 보안 위험을 유발하고 있으며, 직사각형 Type으로 이 보안 위험을 막을 수 있다고 합니다.
  2. master branch를 가져온 다음에 hotfix/shape branch를 만들어 줍니다.
  3. bug를 fix한 후 git commit합니다. 내용은 "[수정] 정사각형 -> 직사각형"으로 작성했습니다.
  4. git push, PR을 수행합니다. 시간이 없기 때문에 Reviewer는 Code Review, 요구사항 충족, Integration Test를 한 번에 Review할 수 있도록 Reviewer를 지정합니다.
  5. Review가 정상적으로 완료되었다면 master branch에 merge를 진행해 운영환경에 즉시 적용합니다.
  6. 이 직사각형 변경사항을 master에만 두면 나중에 master branch에서 충돌할 수 있으므로 develop branch에도 hotfix 내용을 반영해야 합니다. 그런데 hotfix 진행 사이에 누군가 추가 feature를 develop branch에 반영했습니다. (Round shape)
  7. 추가된 수정사항까지 반영해서 PR을 해야 하므로 git pull origin develop을 진행하여 Merge한 다음에 git commit, git push, PR을 수행합니다. message로는 "[병합] 초록색 둥근 모서리 직사각형" 이라 작성합니다.
  8. Reviewer는 develop branch에 hotfix사항도 Merge합니다. 이는 차후에 Release에 hotfix로 인한 master branch merge conflict 가능성을 없애줍니다.

 

 

이렇게 해서 운영 Issue를 빠르게 해결하는 방법에 대해서 알아보았습니다. 이 Case의 Process는 무엇보다 빠르면서도 정확한 운영 Issue 해결이 목적이며, 또한 잠재되어 있는 hotfix 형상관리 문제도 해결해 주는 좋은 Process입니다.

 

 

 

마치며...

이렇게 해서 Git-Flow 전략 운영에 대해 3가지 Case를 통해 알아보았습니다. Git-Flow는 많은 사람들이 모여 개발을 진행할 때 적합한 전략입니다. 1인 개발을 진행할 때에는 Developer, Maintainer 구분 자체도 없기 때문에 Git-Flow 전략보다는 GitHub-Flow가 더 적합할 것입니다. 상황에 맞춰서 적절한 Git Branching Strategy를 선택하도록 합시다. 감사합니다.

 

 

 

 

 

 

 

* reference

https://git-scm.com/

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

https://medium.com/@sreekanth.thummala/choosing-the-right-git-branching-strategy-a-comparative-analysis-f5e635443423