[Git] Git branch 전략 (Git Flow / Github Flow)

▼ Why ?

Git branch를 공부하다 보니 Git branch 전략이라는 것에 대해 알게 되어 추가적으로 공부하게 되었고, 협업 과정에서 충돌을 방지하기 위해선 Pull Request를 알아둬야 할 필요가 있다고 해서 공부하고 정리하게 되었다.

---

▼ Git Flow

 

• Git branch를 보다 효과적으로 관리하기 위한 workflow 중 하나이다 (가장 익숙한 branch 전략)
  
  
• Git Flow는 Main branch, Develop branch, Supporting branch로 구분하여 branch를 관리한다
  
  

Main branch

• 출시 가능한 Production 코드를 모아두는 branch
  
  
• 프로젝트 시작 시 생성되며, 개발 프로세스 전반에 걸쳐 유지된다
  
  
• 배포된 각 버전을 Tag를 이용해 표시한다

 

Develop branch

• 다음 버전 개발을 위한 코드를 모아두는 branch
  
  
• 개발이 완료되면, main branch로 병합(merge)된다

 

Supporting branch

• Feature branch
  
  
  • 하나의 기능을 개발하기 위한 branch
    
    
  • develop branch에서 생성하며, 개발 완료되면 다시 develop branch로 병합(merge)된다.
    ➠ 단, Fast-forward 방식으로 merge 하지 않고, Merge Commit을 생성하며 merge 해야 한다 !
    
    
• Release branch
  
  
  • 소프트웨어 배포를 준비하기 위한 branch
    
    
  • Develop branch에서 생성하며, 버전 이름 등의 소소한 데이터를 수정하거나 배포 전 사소한 버그를 수정하기 위해 사용된다
    
    
  • 배포 준비가 완료되면, main & develop branch에 merge한다
    ➠ main branch에는 Tag를 이용하여 버전을 표시
    
    
• HotFix branch
  
  
  • 이미 배포된 버전에 문제가 발생했을 때 해결하기 위한 branch
    
    
  • main branch에서 생상하며, 문제 해결이 완료되면 main & develop brance에 merge한다

 

 특징 & 한계

• 각 용도에 맞게 branch를 분리(Production 관련 branch ⟺ Develop 관련 branch)해서 사용할 수 있어 운영 환경에 어떤 코드 베이스가 배포되어 있는지 한 눈에 확인할 수 있다
  
  
• 명확한 release 기간과 주기적인 버전이 정해진 Product를 개발하는 환경에 적합
  ➠ 스마트폰 어플리케이션, 오픈소스 라이브러리 / 프레임워크 등의 프로젝트
  
  
• release 버전 관리를 위한 release branch를 따로 관리하기 때문에, 특정 버전에 대한 유지 보수 기간이 길고, 여러 버전을 동시에 관리해야 할 필요가 있을 때 유용하다
  ➠ 규모가 큰 팀에 어울린다 !
  
  
• 특성상 항상 최신의 단일 버전만 사용하는 웹 어플리케이션 개발엔 Git Flow는 다소 적합 X
  ➠ Github Flow를 사용해보자 !

 

---

▼ Github Flow

 

• Github 환경에서 사용하기 적합한 branch 전략, 자동화를 적극 활용
  
  
• Git FLow에서 develop, realses, hotfix branch를 제거한 형태
  ➠ 단일 버전이 있는 Product를 위한 전

Main branch

• 항상 안정된(Stable) 상태이어야 한다 (강제하는 유일한 사항)
  ➠ 즉, 모든 commit은 언제 배포하든 문제가 없어야 하며, 언제든 branch를 새로 만들어도 문제가 없어야 한다는 것이다
  ➠ main branch의 모든 commit은 build가 되고 test를 통과해야 한다

 

Topic branch

• 새로운 기능을 개발할 때 main branch로부터 생성하는 branch
  (Git Flow의 feature branch와 동일한 역할)
  
  
• 별도로 hotfix branch를 관리하지 않아, 버그 수정도 topic branch에서 관리
  
  
• topic branch의 이름은 기능을 설명하는 명확한 이름으로 지어줘야한다
  
  
• 기능이 완성되지 않았더라도 꾸준히 push 해주기 때문에 커뮤니케이션을 상시 유지 가능

 

Github Flow 전략이 적절한 경우

• 특성상 항상 최신의 단일 버전만 사용
  
  
• 별도의 배포 주기를 가지지 않는다
  
  
• 각 기능이 짧은 주기로 PR(Pull Request)을 거치고 나면 빠르 병합(merge)한다
  
  
• 버그에 대한 가장 빠른 롤백 시나리오가 필요하지 않다

 

---

▼ PR ( Pull Request )

 

Fork

• 다른 저장소에 있는 Repository를 내 원격 저장소(GitHub)로 가져오는 작업
  ➠ 쉽게 말하면 해당 Repository에 Contribute(기여자)로 등록된 것은 아니지만
  해당 프로젝트를 함께 작업하는데 도움을 준다
  
  
• Fork해온 Remote Repository를 내 Local Repository에 Clone 한 후 코드를 수정한다
  ➠ 이렇게 수정한 코드를 원래의 Repository에도 반영이 됐으면 했을 때, Pull Request를 보내는 것 

 

Pull Request

• 수정한 코드가 있는 branch를 가져가 검토 후 병합(merge)해달라고 요청하는 작업
  
  
• PR은 코드 충돌을 최소화할 수 있고 push 권한이 없는 오픈 소스 프로젝트에 기여할 때 많이 사용
  
  

 

1. 내 Remote Repository에 Fork
   
   
2. Fork한 Repository (Remote Repository) 를 Local Repository로 Clone
   
   
3. Fork를 수행헀던 Origin(원본) Repository도 Remote Repository로 등록
   
   
4. 복사해 온 코드를 개발하기 위한 용도로 새로운 branch를 생성
   
   
5. 코드 작업 후 add / commit / push 하여 반영
   
   
6. Pull Request 생성 (Compare & pull request 버튼 클릭)
   ➠ PR 요청
   
   
7. Merge Pull Request
   ➠ Origin Repository 관리자가 해당 변경 내용을 검토하고 merge 여부를 결정
   
   
8. Merge가 완료되면 Local Repository의 코드와 Origin Repository의 코드를 동기화하자
   
   
9. 코드를 수정하기 위해 새로 생성한 branch는 삭제