현재 상황은 어떤데?
현재 우아한테크코스에서는 프론트 코드와 백엔드 코드가 같은 레포지토리를 사용하고 있습니다.
프론트와 백엔드가 같이 작업하기에, 의도치 않은 충돌이 자주 생길 수 있는 구조이기에, 이를 git branch 전략으로 충돌을 줄이고자 합니다
Git Branch 전략이란?
git을 사용해서 소프트웨어 개발을 관리하는 방법입니다.
여러 개발자가 동시에 작업하고 코드를 통합할 때 생기는 충돌을 효율적으로 조정하기 위한 방법입니다.
왜 git branch 전략이 중요한데?
아래에 있는 4가지를 제외하고도 훨씬 많은 장점이 있을 수 있습니다.
1. 동시 작업이 편하다
여러 사람이 독립적으로 작업하고, 커밋을 할 때, 자신의 브랜치에서 변경 사항을 커밋하게 됩니다.
브랜치가 병합될 때만 충돌을 해결하면 되니, 아무 규칙이 없는 것보다 충돌 시점이 명확해지기에 생산성을 높일 수 있습니다.
2. 목적이 명확한 브랜치
애플리케이션의 상태에 몇 가지가 있는데, 안정된 프로덕션, 테스트 환경, 기능 추가 환경... 등이 있습니다
여러 기능별 브랜치(안정된 버전의 코드만이 관리되는 브랜치, 테스트 환경을 위한 브랜치, 기능 추가를 위한 브랜치)를
네이밍을 통해 구분하면 각각의 브랜치에 대해서 추가적인 설명을 할 필요 없이 명확하게 관리할 수 있습니다.
3. 배포 파이프라인 관리가 편함
브랜치가 네이밍으로 명확하게 구분이 되어있다면, 조건을 설정하기 쉽습니다.
특정 타입의 브랜치에 push 되었을 때, pull request를 만들었을 때 같은 조건에 따른 스크립트를 만들어둔다면 CI/CD를 구축하기 쉽습니다.
4. 버전 관리가 편리하다
서버에 문제가 생겼을 때, 어떤 브랜치로 돌아가서 롤백을 해야 하는지에 대한 것들이 명확합니다.
안정된 브랜치가 어떤 것인지 명확하기에, 롤백 과정에 대한 의사결정을 줄일 수 있습니다.
그러면 어떤 종류가 있는지 더 자세하게 알아보도록 하겠습니다.
Git Branch 전략의 종류는?
총 3가지의 전략이 있습니다.
1. Github Flow
2. Gitlab Flow
3. Git Flow
git을 사용하기에, Git Flow라는 네이밍이 가장 직관적이고 유명한데요.
3가지 전략 중에서 가장 복잡하기에, 쉬운 순서대로 진행해 보도록 하겠습니다.
1. Github Flow
그림으로 flow 간단하게 보고 가도록 하겠습니다.
브랜치는 총 2가지 종류가 존재합니다
1. master 브랜치
여기에 머지가 되면 배포가 되도록 CD를 연결해 놓은 경우가 많습니다.
안정된 버전의 코드가 관리되는 브랜치입니다.
2. feature 브랜치
기능 추가, 버그 수정 등 모든 작업은 feature 브랜치에서 일어납니다.
master 브랜치에서 새로운 브랜치를 만들어서, 마스터로 머지되는 단순한 사이클을 가지고 있습니다.
장점
위에서 볼 수 있는 것처럼 2종류의 브랜치만 있기에, 정말 간단합니다.
학습 과정까지의 러닝 커브가 거의 없다시피 하기에, 간단한 프로젝트에 적용하기 정말 좋습니다.
릴리즈 되지 않은 코드가 최소화됩니다. 최신 버전의 코드와 최대한 빠르게 동기화를 계속해서 시킬 수 있습니다
단점
모든 코드는 다 master 브랜치에 머지가 되어야 한다는 점이 개발 서버와, 운영서버를 나누기 애매할 수 있습니다.
개발 서버에 배포를 하고 싶은 상황이라면, master에 머지가 되어야 합니다.
머지가 된 이후에 cd 파이프라인을 통해서 개발 서버와 운영 서버 모두에 배포가 됩니다.
여러 환경을 나누고 관리를 하고 싶으시다면 다음에 소개해드릴 전략을 사용해 보셔도 좋을 것 같습니다
2. Gitlab Flow
그림으로 flow 간단하게 보고 가도록 하겠습니다.
밑에 환경은 총 2개의 서버가 존재할 때를 가정하고 있습니다.
1. pre-production 서버
2. production 서버
편의를 위해 main에 머지되는 과정은 간단하게 표현했습니다.
브랜치 종류
총 3가지 브랜치가 필요하고, 추가에 따라서 더 추가할 수 있습니다.
1. main(or develop) 브랜치
기능에 대한 개발이 완료되었지만, 여기에 머지되어도 바로 배포되지는 않습니다.
2. feature브랜치
기능을 개발하는 브랜치입니다. Github Flow 와도 유사합니다.
3. production 브랜치
실제 배포가 일어나는 브랜치입니다.
여기에 머지가 되는 순간 배포가 일어납니다.
위 사진에 있는 것처럼, 필요에 따라서 pre-production이나, staging 같은 환경에 따른 브랜치를 추가할 수 있습니다.
특징
1. 무조건 단방향으로 머지가 일어납니다.
긴급하게 라이브 서버에 수정을 해야 할 때, production 부터 시작하는 것이 아닌, main 부터 차근차근 올라가야 합니다
2. 환경에 따라 브랜치 종류가 늘어날 수 있습니다.
위 사진에서는 pre-production 이 그 예시가 되겠네요.
장점
1. Github Flow에서 환경별 브랜치를 통해서 개발 서버나 pre-production 서버에 버전을 깔끔하게 관리할 수 있습니다.
3. Git Flow
브랜치 전략 중 가장 처음으로 유명해진 브랜치 전략입니다.
배포가 특정 주기를 가지고 있는 애플리케이션일 때, 가장 적합합니다.
가장 복잡한 전략을 가지고 있어서, 모두가 브랜치 전략에 대해서 이해하고 있다면 역할에 따른 깔끔한 분리가 가능합니다
그림으로 보고 가도록 하겠습니다
가장 유명한 브랜치 전략이지만, 가장 어려운 전략이기도 합니다.
특징
1. 브랜치에 대해서 양방향으로 머지가 일어납니다
release 브랜치에서 버그 수정이 일어나면, develop 브랜치에도 머지해줘야 합니다.
hotfix 브랜치를 main 브랜치뿐만 아니라, develop 브랜치에도 머지해줘야 합니다
브랜치의 종류가 5가지나 됩니다
1. main
production 이 배포되었을 때, 이 브랜치에 머지되는 것이 기준이 됩니다.
2. develop
위에서 설명드렸던 브랜치들과 큰 차이가 없이 배포 전 브랜치입니다.
3. feature
기능을 개발할 때 사용하는 브랜치입니다. 이것도 위와 큰 차이가 없습니다
4. release
Gitlab Flow에서 pre-production에 해당한다고 봐도 무방합니다.
여기서 버그 수정이 일어났을 경우에, develop에 머지하는 것을 까먹으면 안 됩니다.
5. hotfix
main 브랜치에서 생성된 브랜치로, 긴급한 변경사항을 처리합니다.
이때, develop에 머지하는 것을 깜빡하면 안 됩니다.
더 자세하게 알아보실 분은 아래 링크들을 확인해 보세요
우리 프로젝트에는 어떤 것이 적절할까?
나중에 개발 서버 혹은 스테이징 서버를 두고 싶기에, 이 부분에 대한 처리가 부족한 Github Flow는 적절하지 않습니다.
Git Flow는 깔끔하게 처리할 수 있지만, 러닝 커브가 Gitlab Flow 보다 약간 더 있어서, 빠르게 개발하는 취지에 맞지 않아 보였습니다.
이런 과정을 통해서 Gitlab Flow를 사용하려고 합니다
참고