Featured image of post Git Workflow
Git

Git Workflow

Git 브랜치를 어떻게 관리할까?

Trunk based

  • 브랜치 관리가 간단하고, CI/CD 와 함께 신속, 지속적인 개발과 배포에 용이
  • 코드베이스가 항상 배포 가능한 상태를 유지하므로, 긴급 수정이나 기능 추가가 빠르게 이루어짐.
  • 모든 개발자가 단일 브랜치에서 작업하기 때문에, 코드 품질과 안정성 관리에 주의가 필요함.

Branch

  • main
  • short-term

Git flow

  • 2010
  • 프로젝트의 안전성과 관리를 높이는데 초점을 맞춤.
  • 브랜치 관리가 복잡하고, 신속한 배포가 어려움.

Branch

  • main
    • 항상 production에 배포 가능한 안정적인 코드를 유지하며, 모든 작업의 기준 브랜치 (permanent)
  • develop
    • 개발자가 feature 브랜치를 merge (permanent)
  • feature
    • 기능 개발을 위한 브랜치로, 개발이 완료되면 develop 브랜치로 merge
  • release
    • 배포 준비를 위해 QA(Intergration Test) 및 bug fix 후 main, develop로 merge
  • hotfix
    • 긴급한 버그 수정을 위한 브랜치로, main에서 분기하여 수정 후 main, develop으로 merge

git flow

GitHub flow

  • 2011
  • git flow 의 복잡성을 줄이기 위해 고안됨.
  • 빠른 개발 및 배포와 피드백

Branch

  • main
    • production에 배포되는 안정적인 버전의 브랜치이며, 좀 더 엄격한 규칙이 필요(permanent)
  • feature
    • 기능 개발을 위한 브랜치로, 개발이 완료되면 main 브랜치로 merge
    • 브랜치명은 작업 내용을 표현할 수 있도록 명명

github flow

GitLab flow

  • 2014
  • Git flow와 GitHub flow의 중간 정도의 혼합 방식
  • 환경 별 브랜치 사용

Branch

  • main
    • 항상 production에 배포 가능한 안정적인 코드를 유지하며, 모든 작업의 기준 브랜치 (permanent)
  • feature
    • 기능 개발이 완료되면 main 브랜치로 merge
  • staging(optional)
    • staging환경에서 변경 사항을 테스트 및 검증하여 문제가 없으면 production으로 병함 (permanent)
  • production
    • 실제 서비스에 배포되는 브랜치 (permanent)

어떻게 적용하면 좋을까?

복잡하고 큰 규모의 프로젝트, 정기 릴리스가 필요한 때 Git Flow를 적용하면 좋을 것 같다. 차량, IOT 기기와 같은 분야에서 많이 이용될 것이고, 참여했던 차량 SW 프로젝트에서 기반으로 한 것이 Git Flow이다.

빠른 변화와 피드백, 하루에도 여러 번의 배포가 이루어진다면 Trunk Based, GitHub Flow 기반의 Workflow를 사용할 수 있다. SaaS, Agile 방식에 적합하고, 단순하지만 그만큼 자동화 테스트, 롤백, 코드 리뷰와 같은 개발 문화 등이 이루어져야 할 것이다.

Workflow는 딱 정하는 것이 아닌 조직, 프로젝트, 여러 가지 현재 상황에 맞추어 가는 것이 필요하다. 실제로 안정성을 위해 ‘feature-develop-main’, ‘feature-main-production’로 구성을 했다가, CI/CD에 unit test, e2e를 적용 후에 ‘feature-main’으로 변경을 했었다.