docs: Git-Flow vs GitHub-Flow

Wannabe-Woowa-Article · Jul 22, 2024 · f15f6e8 · f15f6e8
1 parent 20d9762
commit f15f6e8
Showing 1 changed file with 104 additions and 0 deletions.
diff --git a/July/article/Git-Flow-vs-GitHub-Flow.md b/July/article/Git-Flow-vs-GitHub-Flow.md
@@ -0,0 +1,104 @@
+## 🔗 [Git-Flow vs GitHub-Flow](https://quangnguyennd.medium.com/git-flow-vs-github-flow-620c922b2cbd)
+
+### 🗓️ 번역 날짜: 2024.07.22
+
+### 🧚 번역한 크루: 소하(최소연)
+
+---
+
+<img src="https://miro.medium.com/v2/resize:fit:1400/format:webp/0*fgnh970Zf7cdoplU"/>
+
+## Git-Flow
+
+Git-Flow는 서로 다른 기능 간의 병렬 개발 요구를 해결하는 방법을 제공합니다. 기능을 개발하기 시작하면 master 브랜치에서 feature 브랜치를 생성합니다. 그런 다음 기능에 대한 모든 개발 작업은 이 feature 브랜치에서 수행됩니다. 기능 작업을 완료한 후에는 릴리스를 위한 주 코드 경로로 feature 브랜치를 다시 병합합니다.
+
+Git-Flow는 다음과 같은 브랜치를 가지고 있습니다.
+
+- Feature 브랜치: 개발자가 기능을 개발하는 데 사용하는 브랜치입니다.
+- Develop 브랜치: 개발된 기능을 수집하는 브랜치입니다.
+- Release 브랜치: 버전 릴리스를 담당하는 브랜치입니다.
+- Hotfix 브랜치: 온라인 결함을 수정하는 브랜치입니다.
+- Master 브랜치: 최신 릴리스된 버전의 기준을 저장하는 브랜치입니다.
+
+<img src="https://miro.medium.com/v2/resize:fit:1400/format:webp/1*hmZzuG8oU7fqsnpfTgKDUw.png"/>
+
+각 기능은 자체 개발 브랜치, 즉 feature 브랜치를 가지고 있습니다. 개발자가 두 개의 기능을 작업해야 할 때, 개발자는 "check out" 명령을 실행하여 브랜치 사이를 전환하기만 하면 됩니다. 이는 개발 과정에서 두 기능의 개발 간 상호 간섭을 방지하기 위함입니다.
+
+기능을 개발할 때는 별도로 검증해야 합니다. 기능이 검증된 후에는 전체 소프트웨어 프로그램을 검증하기 위해 develop 브랜치라는 통합 브랜치에 병합합니다. 이 과정에서 develop 브랜치는 대부분의 경우 master 브랜치와 유사합니다. develop 브랜치는 항상 최신 미출시 버전을 저장합니다. develop 브랜치에 있는 코드가 검증되어 출시할 수 있게 되면, 출시를 위해 develop 브랜치에서 release 브랜치를 생성할 수 있습니다.
+
+출시 과정에서 release 브랜치에 결함이 발견되면, release 브랜치에서 결함을 수정하고 수정 사항을 develop 브랜치에 동기화합니다. release 브랜치에 있는 버전이 출시된 후에는 최종 코드를 다시 develop 및 master 브랜치에 동기화합니다. 이렇게 하면 master 브랜치는 항상 작동 버전의 기준을 유지합니다. 한편 develop 브랜치는 개발 통합을 위한 최신 버전을 유지합니다.
+
+Git-Flow는 온라인 결함을 수정하는 데 전용으로 사용되는 hotfix라는 브랜치를 도입합니다. 결함이 수정된 후에는 develop 브랜치에 수집되고, 그다음 master 브랜치에 동기화됩니다. 사실, hotfix는 특수 기능 브랜치로 간주할 수 있지만, 이를 통해 제출된 코드 변경 사항은 develop 브랜치에 통합되는 동시에 master 브랜치에 동기화되어야 합니다.
+
+---
+
+- 개발자들은 개발 요청을 받아 develop 브랜치에서 feature 브랜치를 생성합니다.
+- 개발자들은 로컬 개발 및 로컬 검증을 완료한 후 코드를 feature 브랜치에 제출합니다.
+- 코드는 feature 브랜치에서 검증되며, 새로 생성된 코드를 지속적으로 병합합니다.
+- 개발자들은 기능 개발을 완료하고 feature 브랜치에서 검증 중에 오류가 감지되지 않습니다. 그런 다음 기능 브랜치의 코드를 개발 브랜치에 병합합니다.
+- **develop 브랜치는 다른 feature 브랜치의 코드가 포함될 수 있는 통합 검증을 수행합니다.** 통합 검증이 완료되면 feature 브랜치는 삭제됩니다.
+- 예를 들어 develop 브랜치가 성숙한 릴리스 버전을 유지할 때, 즉 develop 브랜치가 전체 테스트를 수행하고 모든 결함을 수정한 경우, **출시를 위해 release 브랜치**를 생성할 수 있습니다.
+- 출시를 완료한 후 **release 브랜치의 코드는 develop 및 master 브랜치에 병합되고**, 그다음 release 브랜치는 삭제됩니다. 여기서 **master 브랜치는 항상 가장 최근에 출시된 코드를 유지**한다는 점에 유의해야 합니다.
+
+hotfix 프로세스는 다음과 같습니다:
+
+- 출시 후 결함이 발견되면 master 브랜치에서 hotfix 브랜치를 생성합니다.
+- 결함을 수정한 후 hotfix 브랜치에서 검증합니다.
+- 수정 사항을 develop 및 master 브랜치에 병합합니다.
+- hotfix 브랜치를 삭제합니다.
+
+### 장점
+
+- 브랜치의 명확한 책임과 함께 완전한 규칙이 있습니다.
+- 전통적인 소프트웨어 배포에 적합합니다.
+- 병합이 번들로 묶이고, 명확하게 레이블이 지정되며, 깔끔하게 추적할 수 있어 매우 철저하고 상세한 버전 제어를 제공합니다.
+- 개발 규모를 쉽게 확장할 수 있습니다. 기능을 격리하고 출시 준비를 위해 develop 또는 master 브랜치를 동결할 필요가 없도록 하여 병렬 처리 및 지속적인 개발을 간소화합니다.
+- 유연한 브랜칭 전략. 개발 파이프라인의 여러 부분(예: 나중에 출시될 기능과 현재 릴리스의 긴급한 우선순위) 사이를 더 쉽게 이동할 수 있습니다.
+- master 브랜치의 코드는 철저하게 테스트되고 정제된 코드만 업데이트되므로 매우 깔끔하고 정돈된 상태로 유지됩니다.
+
+## 단점
+
+- 복잡한 규칙이 있는 많은 브랜치
+- 출시된 버전에 대한 유지 관리 작업량이 많음
+- Git-Flow의 엄격한 구조와 특정 개발 경로는 애자일 방법론의 반복적인 접근 방식과 충돌합니다.
+
+## GitHub-Flow
+
+Git-Flow와는 달리 GitHub-Flow는 릴리스 브랜치를 사용하지 않습니다. GitHub-Flow의 개념에 따르면 버전이 준비되면 바로 배포할 수 있습니다. 마찬가지로 GitHub-Flow는 hotfix가 사소한 기능 변경과 동일하다고 믿으며, 처리 방법도 유사해야 한다고 생각합니다.
+
+- **master 브랜치의 모든 코드는 배포할 수 있는 최신 작업 버전입니다.**
+- 새로운 작업을 수행하려면 master 브랜치에서 새 브랜치를 만들고 목적을 명확하게 나타내기 위해 명시적으로 이름을 지정합니다. 예를 들어 새로운 일정 전략이라는 이름을 지정합니다.
+- 코드 변경 사항은 가능한 한 자주 로컬 브랜치에 커밋해야 합니다. 한편 변경 사항은 가능한 한 자주 서버의 동일한 브랜치 이름의 브랜치와 동기화해야 합니다.
+- 새 코드를 master 브랜치에 병합하려면 **코드 검토를 요청하기 위해 풀 요청을 시작**해야 합니다.
+- 코드 검토가 통과되거나 코드 검토가 진행 중인 경우 **브랜치는 검증을 위해 테스트 환경에 배포해야 합니다.**
+- 검토와 검증이 통과되면 코드를 master 브랜치에 병합해야 합니다. 따라서 master 브랜치는 항상 배포 가능합니다.
+- 최신 릴리스 패키지는 master 브랜치의 최신 코드에서 생성됩니다.
+
+hotfix 프로세스는 다음과 같습니다:
+
+- 출시 후 결함이 발견되면 master 브랜치(프로덕션 환경에 배포된 특별 커밋 버전)에서 hotfix 브랜치를 만듭니다.
+- 결함을 수정한 후 hotfix 브랜치에서 검증합니다.
+- hotfix 브랜치를 master 브랜치에 병합합니다.
+- hotfix 브랜치를 삭제합니다.
+
+<img src="https://miro.medium.com/v2/resize:fit:1400/format:webp/1*bvubr15Z_l3UknX1w8Mx1A.png"/>
+
+### 장점
+
+- 명확하고 간단한 협업 규칙
+- 지속적인 통합 및 배포
+- 빠른 피드백 루프를 권장하여 팀이 문제를 빠르게 식별하고 변경할 수 있습니다.
+- GitHub Flow에서는 지속적인 배포가 거의 필수입니다. 완성된 기능이 자리 잡고 출시를 기다리는 develop 브랜치가 없습니다. → 빠르게 생성된 것이 가치를 전달하게 됩니다.
+- 이 브랜칭 전략을 사용하면 기술 부채의 위험이 줄어듭니다. Git-Flow에서는 한 가지 단축키 또는 최적화되지 않은 코드 조각이 빠르게 묻혀 리팩토링 악몽이 될 수 있습니다. GitHub-Flow가 강조하는 얕은 구조와 작은 변경 사항은 장기적으로 기술 부채를 식별하고 관리하는 데 도움이 됩니다.
+
+### 단점
+
+- GitHub Flow는 Git-Flow만큼 잘 조직되어 있지 않습니다. 속도는 포괄성을 희생하여 얻은 것이며, 전체 개발 프로세스를 관리하기 어렵게 만들 수 있습니다.
+- 이 브랜칭 전략은 지속적인 배포를 강조합니다. 일부 소프트웨어 팀에서는 잘 작동할 수 있지만, 다른 팀은 대규모 릴리스를 시도하거나 배포 전에 여러 기능을 함께 테스트하려는 경우 제한적이라고 느낄 수 있습니다.
+- master 브랜치는 생산 및 develop 브랜치로 모두 기능하기 때문에 더 쉽게 혼잡해질 수 있습니다. 출시 준비와 버그 수정 모두 이 브랜치에서 발생하며, 추가적인 주의가 필요합니다.
+
+## 어떤 Git 워크플로우가 적합한가요?
+
+개발 팀이 소규모 애자일 팀이고 각 저장소에 대한 제품에 대해 단일 릴리스 버전이 있다고 가정해 보겠습니다. **GitHub-Flow**가 승자입니다.
+
+GitHub-Flow는 지속적인 배포 및 릴리스를 지원하는 간단하고 효과적인 방법입니다. 이를 통해 팀이 새로운 기능 및 버그 수정에 대한 명확하게 정의된 프로세스를 중심으로 정렬하고 파이프라인을 최대한 간결하고 배송 중심으로 유지할 수 있습니다. 단, 팀이 브랜칭 전략을 준수하도록 해야 합니다.