git rebase 전략

생각없이 merge만 했던 나날들의 모습

세번째 프로젝트에서 만난 팀원이 rebase라는 신문물을 들고왔다.
rebase를 쓰면 깃 그래프가 깔끔해 진대서 얼마나 깔끔해지나 봤더니...

📌 기존 작업 방식

그래프 역행한거 누구냐?ㅋㅋ 하고 웃었는데
나였음...
아찔하다

• 기존에는 원격 브렌치에 내 작업 브렌치를 push 하고, GitLab으로 FE(BE)브렌치에 merge request를 보내는 방식으로 프로젝트를 진행했다.
• merge request는 FE/BE리더가 받으며, 머지 과정에서 일어나는 충돌 또한 FE/BE 리더가 해결한다.
• 지난 프로젝트에서는 내가 FE 리더 역할을 수행했기에, merge 하고 충돌을 해결하는 과정에서 다른 사람이 짠 코드를 확인할 수 있다는 나름대로의 장점이 있었다.

이는 merge(recursive) 전략에 해당하며, main 브렌치에 비해 my-branch가 최신 브렌치가 아니기에 main과 my-branch를 공통 부모로 한 새로운 Merge commit을 생성하는 과정이다.

📌 rebase란?

• Rebase는 글자 그대로 base를 다시 정의한다는 뜻이다. 그림과 같이 my-branch는 원래 main의 B를 base로 가지고 있었지만, C지점으로 base를 옮기고 기존에 있던 Commit을 재정렬 하는 것이 Rebase이다.

• rebase를 전파한 친구와 팀장이 머리를 모아, "뭔지 모르겠으면 일단 이거 보고 따라하기라도 하라"며 다음과 같이 명령어 메뉴얼도 만들어 뒀다.
  덕분에 무지성으로 따라한 후 이와 같이 정리할 수 있었다.

⭐ rebase 활용

1. 변경사항 커밋
   • git add .
   • git commit -m ‘[FE] Feat: 커밋 메시지’
2. 상위 브랜치 (fe) 이동 & pull
   • git checkout fe
   • git fetch ⇒ 변경사항 있는지 확인!
   • git pull origin fe ⇒ 그 다음에 pull 받기!! 꼭!!!!!
3. 하위 브랜치 (fe-branch) 이동 & rebase & pull
   • git checkout fe-branch
   • git rebase fe → fe-branch를 fe브랜치의 최신 변경 사항 위에 다시 적용. fe-branch에서의 작업을 fe브랜치의 최신 내용과 결합하여 새로운 커밋 히스토리를 생성. 이것은 일반적으로 fe브랜치를 최신 상태로 유지하면서 작업 브랜치의 변경 사항을 통합하는 데 사용
     
   • git push origin fe-branch
4. 상위 브랜치 (fe) 재이동 & merge ⇒ 단순히 fe 내용을 받아온다면, 필요 없는 작업!
   • git checkout fe
   • git merge --no-ff fe-branch
5. push로 완성!
   • 주의!!! ⇒ git graph 로컬의 fe가 잘 되어있는지 확인!
   • git push origin fe

💡주의

이미 원격 저장소에 push한 커밋은 절대 rebase하면 안됨.

Rebase는 기존의 커밋을 그대로 사용하는 것이 아니라 내용은 같지만 다른 커밋을 새로 만드는 것.

📌rebase 적용의 장점

• 훨씬 깔끔하고, 알아보기 쉬운 깃 그래프를 확인할 수 있다.
• Rebase는 커밋을 선형으로 재배치하기 때문에, 히스토리가 간결해지고 특정 커밋으로 롤백하기가 상대적으로 단순했다.

여담으로, 커밋 컨벤션도 프론트엔드는 머릿말에 [FE], 백엔드는 머릿말에 [BE]를 붙이도록 수정했더니 각각의 커밋을 알아보기 더욱 쉬워졌다.앞으로 사이드 프로젝트에서 커밋 컨벤션을 정할 때 제안해 봐야겠다!