[Git] merge 순서 이해하기 (git rebase)

💡 merge history 순서는 브랜치 checkout 순서에 영향을 받는다.

• checkout 순서대로 영향을 받도록 하면 협업 시 커밋 로그가 이상해질 것이다.

  • 결론부터 말하면 git rebase를 해주고나서 merge를 해줘야 checkout 순서에 영향을 받지 않는다.
  • 다만, dev나 main에는 항상 rebase(log을 예쁘게 남기기 위한)를 사용하지 않는 것이 좋다.

일단 커밋 로그가 만들어지도록 커밋 몇 개를 날려보자.

💡 log를 잘 보면 feat/join 브랜치를 먼저 merge하고 feat/login을 merge했는데도 먼저 생성한 feat/login이 먼저 커밋 로그에 남아있는 것을 볼 수 있다.

• 이를 해결하기 위해 merge 전에 rebase를 해줘야 한다.

• 개발 브랜치에 새로운 merge가 발생했을 때

💡 git rebase는 공통 Base를 가진 두 Branch가 있다고 할 때, 한 Branch의 Base를 다른 Branch의 최신 커밋으로 branch의 Base를 옮기는 작업이다.

개발 브랜치 dev라 할 때, 내가 다른 브랜치에서 개발 중 dev에 다른 코드가 merge가 되었다면 다음과 같이 해야한다.

  1. git checkout dev
  2. git pull origin dev
  3. git checkout 작업하던 브랜치
  4. git rebase dev

merge를 하는 것보다 git history가 깔끔해진다.