Git Flow 란?
- 나처럼 Github에서 push, merge, pull 정도만 해본 초급개발자라면 이 Git flow라는 말을 한 번쯤은 들어보았을 수도 있다. (한 번도 들어보지 못했다면 이번 기회에 알아두는 것이 좋겠다)
- 실무에서도 역시나 Git을 사용하는곳이 많고 각 회사별로 깃을 사용하는 방법도 다양할 것이라 생각한다. 그중에서도 규칙(?)처럼 "우리는 Git을 이러한 규칙으로 사용한다"는 전략이 존재한다.
- 그 전략중 Git-flow와 GitHub-flow 그리고 *Gitlab-flow *세 가지 전략을 설명하려고 한다.
우선 이러한 전략(규칙)이 왜 필요한지에 대한 이야기부터 해보자.
Git Branch 전략이란?
- 우리가 일반적으로 프로그램 혹은 어플리케이션을 개발할 때 혼자서 모든 것을 개발하지는 않는다. 그러면 공용저장소를 사용하게 될 것이며 이 공용저장소의 소스코드파일을 구현이 끝날 때마다 업데이트를 해줄 것이다.
- 이러한 협업은 대부분은 Git을 사용해서 관리할 것이고 저장소는 GitHub, Gitlab 혹은 일반 서버컴퓨터의 Git만을 설치해서 활용하는 등의 여러 파일관리방법이 존재할 것이다.
- 이때 이 Git을 여러 개 발자가 보다 잘 활용하기 위한 전략(규칙)으로써 생겨난 것이라 생각하면 좋겠다.
결론적으로 1개의 저장소에서 소스코드를 효율적으로 관리하고 협업을 수월하게 할 수 있도록 도와주는 규칙이다.
이제 각각 전략이 어떠한 특징과 차이점이 있는지 알아봅시다.
1. Github Flow
github flow는 git flow보다는 간결하게 활용할 수 있도록 등장한 전략입니다.
[이미지 출처] (https://lucamezzalira.com/2014/03/10/git-flow-vs-github-flow/)
위 그림과 같이 main 브렌치를 항상 배포가능한 최신상태로 유지하는 방법이며 브렌치를 생성할 경우 브렌치이름을 명확하게 정해야 합니다. 특별하게 feature 브렌치나 develop브렌치가 존재하지 않기 때문에 그때그때마다 상황에 맞게 특정 브렌치를 생성 -> 작업 -> 반영 -> 삭제 순으로 흘러가야 합니다. 또한 반영할 때 Pull Request를 생성하여 팀원들과의 코드리뷰 후 반영해야 합니다.
마스터브렌치는 라이브환경의 서버와 자동으로 동기화되어 있고 CI/CD가 자동화되어있어야 합니다. 수동으로 매번 main 브렌치를 반영하기에는 비효율적입니다.
이처럼 Github flow는 소규모 팀에서 선택하기 좋은 전략입니다.
2. Git Flow
[이미지 출처] (https://lucamezzalira.com/2014/03/10/git-flow-vs-github-flow/)
git flow전략은 위 그림과 같이 5개의 브렌치로 master, hofixes, release, develop, feature 브렌치가 존재합니다.
브렌치의 순서는 feature -> develop -> release -> master순으로 가게 되며 master브렌치의 운영 중 이슈가 발생할 경우 hotfixes브렌치로 이동합니다.
- master : 라이브(운영) 서버에 제품으로 출시되는 브렌치
- develop : 다음 출시 버전을 대비하여 개발 중인 브렌치
- feature : 추가기능 개발 브렌치
- release : 다음 버전 출시를 준비하는 브랜치 주로 QA, Test과정이 진행된다
- hotfix : master브렌치에서 발생한 이슈를 수정하는 브렌치
브렌치는 위와 같이 목적에 맞게 사용되어야 하는 방식으로 이루어져 있습니다.
git flow의 흐름으로는 가장 핵심이 되는 master, develop 두 개를 운용해야 합니다. 나머지 feature, release, hotfix 브렌치는 사용하지 않는다면 지우더라도 문제가 되지 않기 때문에 프로젝트를 어떤 방식으로 활용하느냐에 따라 달라진다.
대부분의 작업은 develop에서 취합한다 생각하면 되며 테스트를 통해 정말 확실하게 변동사항이 없을 때 master와 병합한다.
3. Gitlab Flow
[이미지 출처] (https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/)
gitlab flow는 github flow에서 main 브렌치를 병합 후 바로 배포할 수 있는 상태로 만들어야 하지만 이를 gitlab flow에서는 바로배포하지 못하는 경우를 고려하여 production 브렌치라는 것이 존재하는 상황이고 이 production 브렌치역시나 master브렌치 사이의 preproduction 브렌치를 두어 브렌치반영에 시간을 두는 방식이다. 그림으로만 보게 되면 github < gitlab < git flow 순으로 복잡한 구조를 나타내는 것 같다
여러 Git Flow방법들 중 각 상황과 개발 목표에 맞춰 적절한 전략을 활용하는 것이 중요할 것이라 생각하며 나와 같은 초급개발자는 전략보다는 오히려 커밋, 푸쉬, 풀, 풀리퀘, 리베이스 등등.. 기본적인 기능을 더 명확하게 잘 사용할 수 있는 것이 우선이라 생각한다.
오늘은 여러 Git Flow 전략에 대하여 알아보았다.
Reference
- https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5
- https://brownbears.tistory.com/603
- https://docs.gitlab.com/ee/topics/gitlab_flow.html
- https://lucamezzalira.com/2014/03/10/git-flow-vs-github-flow/
- https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/