TIL50 | Git Workflow & Rebase

Git Workflow

Git-flow 전략

• 5가지 종류의 브랜치가 존재한다.
• 항상 유지되는 메인 브랜치 : master, develop
• 일정 기간 동안만 유지되는 브랜치 : feature, release, hotfix

• master : 제품으로 출시될 수 있는 브랜치
• develop : 다음 출시 버전을 개발하는 브랜치
• feature : 기능을 개발하는 브랜치
• release : 이번 출시 버전을 준비하는 브랜치
• hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

📍️ 우아한 형제들 Git-flow 참고하기

 

Git Rebase

Merge

• 불필요한 merge commit이 생성된다.
• 모든 feature branch마다 "merge commit"이 남기 때문에 branch history가 지저분해지기 쉽다.
• "merge commit"자체는 시점과 누가 merge했는지 정도만 알지 중요한 정보는 없다.
• main 브랜치에 다른 브랜치들의 commit이 남아있어서 지저분하다.
• 독립된 브랜치에서 로직 하나를 작성하고 수정하더라도, 다른 작업과 그 내역이 겹쳐 구분하기 어렵다(프로젝트의 history가 복잡해진다.)

 

Rebase

• 불필요한 merge commit이 없다.

• 브랜치 별로 commit이 유지될 수 있도록 한다.(합쳤을 때 섞이는 것이 아님)

• commit의 base를 변경하여, commit history를 일렬로 잘 정리해준다. (줄 지어서 연결되는 느낌)

  # 해당 브랜치의 base commit을 확인하는 방법
  
  > git merge-base main feature/sign-in

• 그 외 명령어

  # rebase가 끝나지 않았을 경우 rebase 진행하기 전으로 돌아감 (트랜잭션과 비슷)
  > git rebase abort
  
  # rebase가 끝났는데 돌아가고 싶을 때
  > git reset --hard

 

Merge vs Rebase

• 브랜치 병합을 다른 방식으로 한다.

• merge는 merge commit이 생성된다.

• rebase는 commit이 너무 많거나 복잡해져서 줄이고 싶다면 commit을 squash해주는 squash옵션을 사용해서 commit을 줄일 수 있다.

  git rebase -i main