image

Git이란?

git은 컴퓨터 파일의 변경 사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 오픈소스 분산 버전 관리 시스템이다. 주로 소프트웨어를 개발하며 코드 관리에도 사용되지만 어떠한 프로젝트의 변경사항을 지속적으로 추적하기 위해 사용될 수 있다. (나는 보통 소스코드 관리와 변경사항 추적을 목적으로 사용하고 있다)

Git-flow란?

Git-flow는 Git이 활성화가 될 2010년 정도에 Vincent Driessen이라는 사람이 만든 Git을 사용한 개발 작업 절차이다. Git-flow라고 해서 프로그램 같지만 프로그램이 아닌 약속, 규칙같은 개념이다. Vincent Driessen또한 Git-flow는 완벽한 방법론이 아닌, 각자 팀에 맞는 개발 환경에 따라 변형해서 사용하는 것이 좋다고 언급했다.

Git-flow의 브랜치

Git-flow의 브랜치는 다음과 같이 구성되어 있다.

  • master: 제품으로 출시(배포)할 수 있는 브랜치
  • develop: 다음 버전을 개발하는 브랜치
  • feature: 단위별로 기능을 개발하는 브랜치 (완료되면 develop 브런치와 병합)
  • release: 배포 전 (master와 병합 전) QA를 통해 버그를 찾아내기 위한 브랜치
  • hotfixes: master브랜치에서 발생한 버그를 긴급하게 수정하는 브랜치

masterdevelop은 항상 유지되는 메인 브랜치들이며 그 외에 feature, release, hotfixes는 필요한 기간에만 유지되는 보조 브랜치들이다.

image

다음은 Vincent Driessen의 블로그에서 Git-flow를 설명할때 사용하는 이미지이다.

타임라인을 보면 알겠지만 처음에는 master로 시작해 develop브랜치만 존재한다. 아직 소프트웨어를 배포하지 않았기 때문에 develop브랜치에서 개발을 시작한다. 개발을 진행하다가 추가로 필요한 기능이 생기면 feature브랜치를 생성해 작업을 한다. feature브랜치는 언제나 develop브랜치로부터 시작된다. 기능을 다 개발했다면 작업한 feature브랜치를 검토한 후 develop브랜치에 병합한다. 이제 이번 버전에서 필요한 기능이 모두 개발되었다면 QA를 위해 release브랜치를 생성한다. QA를 진행하며 발견하는 버그들은 모두 이 release브랜치를 통해 fix된다. 이제 QA과정이 모두 끝났다면 release브랜치를 masterdevelop브랜치로 병합한다. 그리고 master브랜치에 버전명시를 위한 태그를 생성 후 배포한다. 여기까지가 기본적인 개발 단계에서의 Git-flow이다.

image

하지만 배포 후에도 버그가 발생하는 경우가 있다. 그렇다면 긴급하게 수정을 해야하는데 그럴 경우 hofixes브랜치를 생성해 발생한 버그를 수정한다. 버그 수정이 완료되었다면 release브랜치가 완료됬을 때와 같이 masterdevelop브랜치로 병합 후 버그 수정을 완료했다는 태그를 추가한다.

버전 태그

보통 소프트웨어를 표시할때 버전은 x.x.x의 형태로 이루어진다. 이 숫자들은 무엇을 의미할까? 버전의 가장 첫 번째 숫자는 Major Version을 의미한다. Major Version은 보통 1로 시작해서 소프트웨어 전체적으로 큰 변화가 생겼을때 버전 업을 한다. 두 번째 숫자는 Minor Version을 의미한다. Miner Version은 보통 0으로 시작해서 없던 기능의 추가나 기존 기능의 수정 등의 변화가 발생했을 때 버전 업을 한다. 마지막 세 번째 자리는 Build or Maintenance Version이라고 하며 자잘한 버그나 내부적 코드 보안 등의 변화가 발생했을 때 버전 업을 한다. 이 버전은 0으로 시작하지만 생략하는 경우도 있다.

결론

Git-flow는 개발 작업 절차 중 하나로 Vincent Driessen라는 사람이 고안해냈다. 최근 2020년 3월 5일에 블로그에 git-flow는 10년전 소프트웨어를 개발할 때 고안한 작업 절차로, 현재에는 더 많은 작업 절차가 있으니 팀의 상황에 따라 작업 절차를 선택하는 것이 좋다고 했다. 특히 팀에서 소프트웨어를 지속적으로 개발하는 경우 github-flow를 추천해줬는데 다음에는 github-flow에 대해 정리를 해볼 생각이다. 공부하면 공부할수록 느끼는 거지만 배움에는 끝이 없는것 같다. (계속 공부할게 생긴다 😓)

본 포스트는 다음 문서를 참고해 작성했습니다.

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

https://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html

http://seorenn.blogspot.com/2012/02/version.html