1.문제
깃허브로 팀 과제를 진행하면서 주먹구구식으로 진행을 한것이 아쉬웠다. 깃허브 협업을 좀 더 잘하고 싶어 전략을 찾아 본 결과 Git flow라는 브랜치 전략이 있더라. 근데 Git flow 실습 과정에서 Fast forward merge를 시도 할 때 git merge --no-ff {병합할 브랜치명} 를 입력해야 하는 부분에서 이해가 가지 않아 진행을 멈췄다.
이 명령어를 왜 입력 하는거지?
2.시도
결과부터 말하자면 커밋 히스토리를 다듬기 위함이었다.
git merge --ff를 할 경우
master 브랜치엔 main2 이후 기준으로 x1, y1 커밋이 남아있다.
git merge --no-ff를 할 경우
master 브랜치엔 main2 이후 기준으로 x1,y1,z1, master부근의 merge commit까지 남아있다.
그렇다면 커밋 히스토리가 왜 중요할까?
커밋은 하나의 의미있는 변경 사항을 말한다.
커밋만 보고도 개발자들이 어떤 사항이 어떤 이유로 변경 되었는지 알 수 있어야 하는데 그러기 위해선 커밋 히스토리를 잘 남기는것이 중요하고 이유는 크게 2가지 이다.
1. 버그가 언제 터졌는지 파악하기가 쉽다
우리가 버전 관리를 할 때 대개는 여러명의 개발자들과 같이 협업을 진행한다. 그러다 보면 자연스레 변경 사항도 많아지게 되고 그로 인해 버그도 발생한다. 이때, 커밋 히스토리가 잘 정리되어 있을수록 버그를 찾기가 쉬워진다. 이전 버전 기록이 잘 남아있을수록 전과 후를 더욱 쉽게 비교할 수 있을 테니까 말이다.
2. 레거시 코드를 수정해야할 때
2년된 회사에 들어갔는데 어떤 코드를 수정해야 하는 일이 생겼다. 그런데 기존 코드를 짠 사람이 없다면? 내가 수정을 해야할 확률이 높다. 그런데 수정을 하는건 그리 단순하지 않아 보인다. 내가 수정한 코드가 기존의 코드랑 잘 섞일수 있다는 보장이 있을까? 굉장히 두려운 상황이다. 이때 의지할것이 바로 당시 개발자가 어떤 의도로 코드를 작성했는지 기록해놓은 커밋 히스토리다.
의미있는 단위로 커밋이 되어있다면 적어도 어떤 의도로 이 코드를 수정했는지 정도는 파악할 수 있다. 그래서 개발자들이 의미 있는 단위의 커밋, 의미 있는 커밋 메세지를 강조하는 것이고 여기에 더해 적절한 머지 전략을 사용하여 가독성이 높고 의미도 있는 커밋 히스토리 그래프를 유지하려고 하는 것이다.
3.배운 것
오늘은 커밋 히스토리를 깔끔하게 만드는 3가지 전략 중 1가지인 merge commit에 대해 알아봤다. 이제 깃 플로우 실습을 다시 해도 되겠다.
추가 공부:
Fast forward 관계란?
"분기한 브랜치가 기존 브랜치의 커밋 히스토리를 포함하고 있는 관계"
Fast-Forward 일 때
브랜치 B는 A에서 분기 되었다. 그리고 X, Y 는 B에서 분기 되었다. 즉, 브랜치 B의 커밋 히스토리는 A-B-X-Y다. 브랜치 A 또한 A-B-X-Y다. 이 들은 FF 관계에 있다고 할 수 있다.
Fast Forward 관계일 때는 별다른 옵션을 주지 않고 병합을 하게 되면 Merge commit은 만들어지지 않고 HEAD의 위치만 변하게 된다.
Fast-Forward 관계가 아닐 때
여기서 --no-ff를 쓰냐 안쓰냐에 따라 커밋 히스토리가 달라진다.
B의 커밋 히스토리는 좀 전의 A-B-X-Y다. 하지만 A의 커밋 히스토리는 A-B-C이다. B의 입장에선 C 커밋을 포함하고 있지 않기 때문에 현재 관계는 FF 관계가 아니다. 이 상태에서 병합을 할 경우 conflict가 발생한다. 또한 FF관계에서 HEAD위치만 변하는것과 달리 실제로 브랜치가 병합된다.
참고 자료 :
https://otzslayer.github.io/git/2021/12/05/git-merge-fast-forward.html
https://evan-moon.github.io/2019/08/30/commit-history-merge-strategy/
