Git 활용 방법과 브랜치 전략

개요

본 문서는 Git을 활용하는 클라이언트, 브랜치 전략, DevOps 등을 정리한 문서이다. Git 자체에 대한 설명, 사용법에 대한 내용은 포함하지 않는다.

GitHub과 GitLab , Git의 효율적인 사용을 위한 클라이언트 

Git을 사용해 버전관리, 소스관리를 하는 사용자라면 필연적으로 듣게 되는 것이 GitHub과 Gitlab이다. 두 서비스 모두 Git을 더 스마트하고 효율적으로 사용하기 위한 웹기반 Git의 3rd party 클라이언트 제품이다. 

GitHub과 Gitlab의 차이를 설명할 때 보통 Gitlab이 GitHub의 확장판, dev ops기능이 추가된 GitHub 등으로 설명되곤 한다. 또, Gitlab은 MIT 라이센스로 코드를 공개함과 동시에 GitHub와 거의 유사한 화면을 구현해 많은 사용자를 끌어들였다. 이후 프로젝트 관리, CI/CD, 패키지 저장소 등의 기능을 추가하여 단순 코드 관리만이 아닌 소프트웨어 개발 전체 라이프사이클을 커버하는 서비스로 발전했다. 

하지만 GitHub도 프로젝트 관리 기능을 강화했고, CI/CD (GitHub action) 및 패키지 저장 기능도 추가해 무료로 서비스하고 있다. 

이외에 컨플루언스 및 지라로 유명한 아틀라시안이 운영중인 비트버킷, SVN제품으로 알려진 tortoisesvn의 tortoiseGit 등 많은 제품이 출시, 서비스 되고 있지만, GitHub가 점유율이 가장 높고, Gitlab이 뒤를 따르며 양분화 하는 추세로 보인다.

GitHub와 Gitlab의 기본적인 소스관리 및 devops외에, Git 도입시 의사결정하는데 중요한 역할을 할 것으로 예상 되는 부분은 “클라우드형 vs 자체 서버구축형”이다. GitHub는 원격저장소에 클라우드 형식으로 올리는 방식이고, Gitlab도 클라우드형식을 지원 하기는 하지만 일반적으로 중앙 서버에 repo를 설치하여 관리하는 방식으로 많이 사용한다. 그리고 비용적인 측면도 크게 작용할 것으로 보인다. GitHub는 실무에서 서비스를 위해 사용한다면 유료결제는 필수이지만, Gitlab는 무제한의 프로젝트 생성과 타 서비스에 비해 매우 큰 10GB의 단일 프로젝트용량을 제공한다. GitHub, GitLab, 비트버킷에 대한 자세한 설명은 잘 정리된 글이 있어 링크로 대체한다. 링크

각 프로젝트에 맞는 Git 브랜치 전략 선택

앞서 말한 GitHub , Gitlab 등 Git 클라이언트 선택도 중요하지만, 그보다 각 상황에 맞는 Git 사용방법론, 정책 수립이 더 중요하다고 생각된다. 특히 브랜치 전략이 실제 업무 및 개발에 있어 중요한 요소인 것 같다. 브랜치 전략에는 정답이 없지만, 통상적인 개발 플로우를 정리하여 제시한 방법론이 존재한다.

이제는 잘 사용하지 않는 SVN은 단일 브랜치 전략을 사용한다. 모든 상황을 제어하는 브랜치가 단 한개이기 때문에 배포버전과 개발버전, Test버전 등이 모두 뒤섞여 관리 자체가 힘들다. 단순히 소스 코드 공유 및 merge툴 정도이다. 이후 Git이 등장하면서 Git 의 브랜치 전략이 등장하는데, Git-flow, GitHub-flow, Gitlab-flow다. 세가지 모두 Git의 브랜치를 어떻게 하면 효율적으로 사용하고 이를 개발 라이프사이클에 잘 녹여낼지 제안하는 방법들이다.

Git-flow는 feature – develop – release – hotfix – master로 브랜치를 구성하는 개발 모델이고, 이는 표준처럼 여길 정도로 대표적인 워크플로우이다. 이 전략은 웹, 앱 등을 가리지 않고 채택되어왔지만, Git-flow를 처음 고안한 nvie라는 개발자는 “웹 애플리케이션은 일반적으로 롤백되지 않으며, 지속적으로 서비스를 제공하기에 소프트웨어를 다양한 버전으로 지원할 필요가 없다. 당신의 팀이 소프트웨어를 지속적으로 제공한다면 GitHub-flow와 같은 간단한 워크플로우 채택을 제안한다.” 라고 말했다. 즉, Git-flow는 버전 관리가 필요한 앱이나 솔루션, 혹은 public API에 적합한 전략이다. 웹 애플리케이션에서 고려할 전략이 아니다.

두번째로, GitHub-flow다. Git-flow가 가진 가장 큰 문제는 너무 복잡한 브랜치 프로세스이다. GitHub-flow는 Git-flow의 복잡성을 제거하고, 브랜치는 master 하나를 두는 방식을 사용한다. master를 제외한 브랜치는 다른 개발자들에게 맡기기 때문에 복잡한 정책이 필요하지 않다. 또, 웹 애플리케이션처럼 상시 배포가 가능한 프로세스에 적합 방법이다. 아래는 GitHub-flow 정책이다.

 

• master는 언제든지 배포가 가능하다.
• 새로운 프로젝트는 master를 기반으로 별도 브랜치를 생성하여 작업을 진행한다.
• 브랜치는 로컬에 commit하고, 정기적으로 원격 브랜치에 push한다.
• 피드백이나 도움이 필요하거나, 코드 병합할 준비가 되었다면 pull request를 만든다.
• 다른 사람이 변경된 코드를 검토한 뒤 승인하면 master에 병합한다.
• 병합된 master는 즉시 배포할 수 있으며, 배포 해야만 한다.

 

세번째는, GitLab-flow다. GitHub-flow가 제시하지 못한 배포, 환경, 릴리즈 및 소스통합 등 다양한 이슈에 대해 지적하고 추가적인 가이드를 제공한다. “코드를 변경하는 목적은 분명하므로 이슈로 생성해서 관리하자.” 라는 이념으로 코드 변경 사유를 투명하게 공개하는 것이 원칙이다. 

위와 같은 전략을 제시한 이들을 포함해 대부분의 브랜치 전략 수립에 관한 주장에서 공통적인 부분은, 각자의 개발 환경과 상황에 맞게 적절한 브랜치 전략을 수립하라는 내용이다. 버전 관리가 필요한 애플리케이션이라 git-flow를 채택하더라도, 제시한 브랜치 중 불필요한 브랜치가 있다면 사용하지 않는 방법, 메인 브랜치를 master 브랜치 하나만 유지하는 전략을 함께 채택하는 방법 등이다. 또한, SVN의 단일 브랜치 전략은 물론, 너무 복잡하고 Depth가 깊은 브랜치 전략은 피하라는 것이 일반적인 주장이다. 즉, 상황에 맞게 브랜치 전략을 수립하되, 브랜치는 단순하게 가져가야한다.

GitOps , Git을 활용한 DevOps

Git으로 수행되는DevOps라는 뜻의 GitOps는 Cloud native application (클라우드 환경에서 애플리케이션을 구축, 배포, 관리 하는 접근 방식)에 DevOps를 어떻게 적용할지에 대한 방법론이다. 즉, 애플리케이션 배포와 운영에 관련된 모든 요소들을 Git에서 관리하는 것이다. 정확히는 쿠버네티스의 manifest파일을 Git에서 관리하고, 배포할 때도 Git에 저장된 Manifest로 배포하는 과정이다. (쿠버네티스, CI/CD등에 대한 기술적 지식이 부족해 간단한 설명으로 마무리합니다. )

GitLab Global DevSecOps 성숙도 조사

  InfoGrab에서 진행한 GitLab Global devSecOps 성숙도 조사에 대한 링크를 남기는 것으로 문서를 마무리한다. 링크