💡 To conclude, always remember that panaceas don't exist. (…) Decide for yourself.
만병통치약은 존재하지 않습니다. 스스로 판단하세요.
- nvie(Git flow의 창안자)
Git & Jira 활용법 강의를 준비하면서 검토했던 문서들 중 읽어볼 만 했던 자료들을 선별했습니다. .
1. 딱 하나의 글만 읽어야 한다면
1) 브랜치 전략 수립을 위한 전문가의 조언들 by 화해 기술블로그
http://blog.hwahae.co.kr/all/tech/tech-tech/9507/
Git 브랜치 전략 수립을 위한 전문가의 조언들 - 화해 블로그 | 기술 블로그
2. 주요 Git 전략에 대한 설명
1) Git flow
(1) Git flow 창안자 Vincent Driessen(nvie) 의 글
If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.
만약 여러분의 팀이 지속적으로 소프트웨어를 배포하고 있다면, 저는 여러분들이 낡은 Git-flow 대신 Github flow처럼 조금 더 가벼운 워크플로우를 선택하기를 제안할게요.
If, however, you are building software that is explicitly versioned, or if you need to support multiple versions of your software in the wild, then git-flow may still be as good of a fit to your team as it has been to people in the last 10 years. In that case, please read on.
하지만 여러분의 팀이 분명하게 버전이 완료된 소프트웨어를 개발하고 있거나 여러 버전의 소프트웨어를 지원해야 한다면 Git flow는 여러분께 여전히 좋은 선택이 될 것입니다.
A successful Git branching model
https://nvie.com/posts/a-successful-git-branching-model/
(2) Atlassian - Gitflow workflow
Gitflow is a legacy Git workflow that was originally a disruptive and novel strategy for managing Git branches. Gitflow has fallen in popularity in favor of trunk-based workflows, which are now considered best practices for modern continuous software development and DevOps practices. Gitflow also can be challenging to use with CI/CD. This post details Gitflow for historical purposes.
Gitflow 는 본래 복잡하고 사용하기 까다로운 레거시 깃 브랜칭 전략입니다. 이 포스트는 역사적 목적을 위해 Gitflow에 대해 자세히 살펴봅니다.
Gitflow Workflow | Atlassian Git Tutorial
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
2) Github Flow
(1) Github flow - Github 공식문서
I travel all over the place teaching Git to people and nearly every class and workshop I've done recently has asked me what I think about git-flow . I always answer that I think that it's great - it has taken a system (Git) that has a million possible workflows and documented a well tested, flexible workflow that works for lots of developers in a fairly straightforward manner. It has become something of a standard so that developers can move between projects or companies and be familiar with this standardized workflow.
제가 Git에 대해 강의하러 다닌 거의 모든 강의와 워크샵에서 “Git-flow” 에 대해 어떻게 생각하는지에 대한 질문을 받았습니다. 그리고 저는 (의역) “좋은 전략이며 사실상의 표준 전략에 해당한다” 고 대답합니다.
So, why don't we use git-flow at GitHub? Well, the main issue is that we deploy all the time. The git-flow process is designed largely around the "release". We don't really have "releases" because we deploy to production every day - often several times a day. We can do so through our chat room robot, which is the same place our CI results are displayed. We try to make the process of testing and shipping as simple as possible so that every employee feels comfortable doing it.
그러면 우리는 왜 깃헙에서 Git-flow 를 사용하지 않을까요? 왜냐하면 우리가 밥먹듯이 배포를 하기 때문입니다. Git flow 전략은 ‘릴리즈’를 기반으로 구성되었습니다. 하지만 우리는 ‘릴리즈’ 를 하느 ㄴ대신 매일 1회 혹은 그 이상 배포를 하고 있습니다. (중략)
https://docs.github.com/en/get-started/quickstart/github-flow
3) Gitlab Flow
(1) Introduction to GitLab Flow - Gitlab 공식문서
https://docs.gitlab.com/ee/topics/gitlab_flow.html
Introduction to GitLab Flow | GitLab
4) 기타
(1) Simple-Git workflow (by Atlassian )
Simple Git workflow is simple - Work Life by Atlassian
https://www.atlassian.com/blog/git/simple-git-workflow-is-simple
3. Git flow 채택 예시
1) 우아한 형제들 - 우린 Git-flow를 사용하고 있어요
Github flow에서 Git-flow 로 변경.
2016년 1월, Github로 소스코드를 이전하면서 Github-flow를 사용하기 시작했습니다. 그러다 2017년 6월부터 Git-flow로 브랜치 전략을 바꾸게 되었습니다.
Git-flow를 사용하게된 이유
기존의 배달의민족 앱의 개발 프로세스는 ‘기획-디자인-개발-QA-출시’ 순서의 흐름으로 차근차근 흘러갔고 3주 주기마다 앱을 출시했습니다. 그 일을 하는 안드로이드 앱 개발자 인원은 보통 2~3명이였습니다.
회사에서는 지속적으로 개발자를 채용했고 어느새 배달의민족 안드로이드 앱 개발자가 5명으로 늘어났습니다. 기획, 디자인, 서버 등 많은 사람들과 흐름을 맞춰야하기 때문에 이 5명이 모두 이번 버전에 포함될 기능을 개발하는 것은 비효율적이였습니다. (무엇보다 iOS 개발자가 부족합니다..) 작업에 따라 개발 기간이 3주 이상이 필요한 작업들이 많아지기 시작한 이유도 있었습니다. 그래서 기존의 개발 프로세스에서 약간의 변화가 생겼습니다.
https://techblog.woowahan.com/2553/
우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그
4. Github flow 유사 전략 채택 예시
1)하루에 1000번 배포하는 조직 되기 (뱅크샐러드)
Git-flow 에서 Github-flow 와 유사한 독자적 방식의 git 전략 사용.
기존의 배포 프로세스를 유지한 채로 하루에 1,000번 이상의 배포를 하는 조직으로 나아가기 위해서는 너무나 많은 고통이 존재했습니다.
먼저 Git-Flow를 활용한다면 하나의 기능을 배포하는 데 있어서 무려 5번의 branch switching이 필요하고, 6번의 Pull Request와 이에 따른 6번의 Code Review가 필요했습니다. 이 말은 다르게 말하면 코드 오너가 6번이나 코드를 리뷰하고 승인을 해줘야 한다는 것이죠. 이렇게 복잡한 프로세스는 자연스럽게 배포를 귀찮은 존재로 만듭니다. 이로 인해 간단한 수정 사항의 경우 develop branch에 merge 한 뒤 배포하지 않는 일이 종종 발생하기 시작했습니다. 이런 배포되지 않은 변경 사항이 쌓이면서 나중에 필요할 때 한 번에 너무 많은 변경사항을 포함한, 부담스러운 배포를 진행해야만 했습니다. 배포 시 변경 사항이 많을수록 장애가 발생할 수 있는 확률은 당연히 증가하기 때문에 개발자에게는 배포는 무서운 존재가 되었습니다.
https://blog.banksalad.com/tech/become-an-organization-that-deploys-1000-times-a-day/