Git Flow
배경
기본적으로 Git 을 사용해 어떤 행동을 하게 된다.
- Commit
- Push
- Pull
이를 활용해 Git 을 사용하게 되는데 Git 을 사용해 개발하는 환경에서 Branch 간의 문제 없이 배포까지 안정적으로 수행하기 위해 사용하는 것이 Branch 를 관리하는 전략이다.
실제로 개발할때는 한 명의 개발자가 아니라 몇 십명의 개발자가 서로 협업해 개발을 하게 된다. 그렇기 때문에 복잡한 상황에서 Git 이 꼬이지 않도록 하는 것이 중요하고, 안정적으로 운영해 나가야 될 코드들만 배포를 시켜야 되는 것도 굉장히 중요하다.
때문에 Git Flow 라는 전략이 탄생했다.
주요 Branch
1. Main(=Master)
실제 운영 환경에 나가 있는 코드만을 가지고 있는 branch, 그만큼 조심스럽게 다뤄야 한다.
2. Dev
main branch 를 베이스로 생성한 branch가 dev branch 이다.
다음 배포에 나갈 내용들을 바로 main branch 에 merge 할 수 없다. 그 대신 dev branch 에 다음 배포에 나갈 feature 개발 건들을 merge 하게 되고, 그 모든 작업 내용을 갖고 있는 branch 가 dev branch 이다.
- Dev 는 Master 를 Base 로 생성된 Branch 이다.
- Dev = Master + @ 의 코드를 가지고 있어야 한다.
- Sync 가 안 맞을 경우 Dev != Master + @ 가 된다.
- 이 상태로 누군가 Dev 에서 신규 Branch 를 생성하게 되면 코드가 꼬이게 된다.
3. Feature
어떤 feature 를 개발을 할 때 branch 를 새로 만들어 그 branch 의 작업 내용을 commit 하고 commit 을 다 했을 경우 dev branch 에 merge 하게 된다.
4. Release
모든 과정이 끝난 다음에 정말 운영에 내보내야 할 시점이 다가왔을 때 dev branch 를 베이스로 release branch 를 생성하게 된다.
release branch 가 왜 필요하냐면, 다음 배포할 코드를 정말로 그 순간에 스냅샷을 만드는 느낌으로 dev branch 에서 release branch 를 생성하게 된다.
release branch 가 생성이 된 시점부터는 dev branch 에 이번 배포에 나갈 내용들을 작업하지는 않는다. 무조건 release branch 에 작업을 추가해 주어야 한다.
release branch 로 실제로 서버를 배포하고 QA나 혹은 개발 테스트를 마무리 지었을 경우에 그 release branch 를 main branch에 merge 를 하게 되고, main branch 를 운영환경에 배포를 하게 된다.
5. Hotfix
의도치 않은 장애사항이 벌어졌을 때 지금처럼 dev branch 를 생성하고 feature 를 만들고 release 를 만들면 이 과정에서 시간이 오래걸리기 때문에 hotfix 는 main branch 에서 바로 hotfix branch 를 생성하고, 당장 수정을 해야되는 최소한의 부분만 수정해서 commit 하고 그 commit 내역을 다시 main branch 에 merge 한 후 main branch 로 운영해 배포를 하게 된다.
마찬가지로 hotfix 이후에도 Master 와 Dev 간 Sync 를 맞추어야 한다.