[Git] Git 브랜치 전략

git 브랜치 전략

기술면접에서 git 브랜치 전략에 대해 질문을 받았는데 dev, master, stage, dev-...(개인)로 배포, 테스트, 개발 브랜치로 나눠 관리하고 있다라고만 답을 했습니다.

제가 풀어서 설명한 방식은 gitflow 전략과 유사했습니다. Atlassian 문서에서 링크된 gitflow전략을 개발한 Vincent Driessen의 포스트에 따르면 10년 동안 gitflow 전략이 정석(혹은 마법의 알약)으로 소프트웨어 업계에 자리잡았다고 합니다.

하지만 필자는 이 전략을 10년 전 CI/CD 주기가 지금보다 훨씬 길었을 때 구상했기 때문에 짧은 배포주기를 가지고 있는 팀은 Github-flow 사용을 권장한다면서 세상에 마법의 알약은 없는 사실을 받아들이라고 말합니다.(변화를 무서워 하면 도태된다는...)

gitflow 구조

[출처: https://nvie.com/posts/a-successful-git-branching-model/]

master에서 시작해 develop 브랜치가 fork/pull 합니다. develop는 다음 배포를 위해 작업을 통합시키는 역할을 합니다. 그리고 최소 작업 단위를 커밋하는 feature branches를 가지고 있습니다. master에서 버그가 발생했을 땐 hotfix 브랜치에서 수정한 뒤 곧바로 master에 merge 해줍니다.

master브랜치는 엄격하게 다뤄져야하며 그 이유는 머지됨과 동시에 git 훅을 사용해 테스트, CI/CD를 자동화시킬 수 있기 때문입니다.

master와 develop 브랜치는 main브랜치로 분류되고, 이외에는 supporting 브랜치로 분류됩니다. 차이는 영속성에 있습니다. supporting브랜치는 라이프타임 사이클에 따라 제거되기 때문입니다.

feature 브랜치는 develop 브랜치에서 파생되며 다음 배포, 또는 예정된 배포를 위해 생성되고 develop 브랜치에 머지된뒤 제거됩니다. 그리고 develop repo를 upstream으로 두고 github forked해서 origin repo에선 존재하지 않아야 합니다.

$ git checkout -b myfeature develop
Switched to a new branch "myfeature"

$ git checkout develop
Switched to branch 'develop'

$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)

$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).

$ git push origin develop

gitflow와 github-flow의 차이는 to be continued...

---

참고자료

• 우아한형제 기술블로그
• Atlassian Bitbucket
• A successful Git branching model
• Github - Understanding of github-flow