Git Workflow & Rebase

• Git flow
• Git merge vs. Git rebase

1. Git flow

• Main branch : 정식으로 서비스하는 배포단계(release) 의 코드가 모이는 곳
  
  
• Develop branch : 개발단계의 코드가 모이는 곳
  • 지금 wecode 에서 실습하면서 사용하고 있는 Main branch 의 느낌
    
    
• Release branch : bug 완료되고, 배포 준비되면 release branch 만듬
  • Main branch 에 올리고, 배포
    
    
• Hotfix : 배포 후(서비스 도중), Main branch 에서 바로바로 고치는 것
  • 원래는 Develop branch 에서 branch 하나 더 만들어 그곳에서 수정 등 작업해야 하는 형태

2. Git merge vs. Git rebase

• merge vs. rebase : 방법만 다를 뿐, branch 병합 을 위해 사용하는 것
  
  
• rebase
  • base : 해당 branch 가 생성될 때의 commit 지점
  • rebase : 기준(=pull request 발생 시점)이 되는 commit을 최신화하여 방금 막 branch 를 생성하여 갖고 있음
    
    
• conflict
  • commit과 commit 사이에서 일어나는 작업 내용 사이의 충돌
  • rebase 하다보면, conflict 많이 발생
    
    
• squash : commit message 를 하나로 합침
  • 해당 branch 에서 작업한 내용을 title (요약) 과 body(상세 내용) 를 통해 하나의 commit message 로 작성
  • 보통 rebase 하면서 squash 작업도 같이 함

(1) merge 수행 시, 문제점

• 불필요한 merge commit 생성
  • 모든 feature branch마다 “merge commit” 이 남음
  • 만약 main 브랜치를 공유하는 개발자가 많고, 프로젝트의 규모가 크다면, branch history 가 지저분해지기 쉬움

• 복잡한 프로젝트 history
  • 독립된 브랜치에서 로직 하나를 작성하고 수정하더라도, 다른 작업과 그 내역이 겹쳐 구분하기 어려워짐
  • 이런 상황을 프로젝트의 history가 복잡하다고 표현함

(2) rebase 의 장점

• merge commit 이 남지 않음
• commit 순서에 관계없이, feature branch 별 commit 으로 구분하여 관리

• Rebase는 내 commit의 base를 변경하여, commit history를 일렬로 잘 정리해줌

• 해당 브랜치의 base commit 확인하는 방법 : git merge-base main feature/sign-in (필수 아님)

<출처> wecode(코딩 부트캠프) 세션