Pintos 주차를 시작한지 2주차가 되었습니다.
userprog 를 진행하면서 저 포함 3명의 팀원과 함께 git hub 를 사용하고 있었습니다.
1주차에 git hub를 적극적으로 활용하지 못했던 점이 맘에 걸려서 ( 거의 commit 1회밖에안함 )
2주차에는
- 각자 의무적으로 커밋수를 늘리고 push 하면서 코드의 커밋이력을 계속 맞추자
라는 목표를 세웠습니다. 그 과정에서 저희가 겪었던 이슈를 설명하겠습니다.
branch 전략
저희가 세웠던 브렌치 전략은 다음과 같습니다.
핀토스의 코드가 워낙 방대하고 수정해야 하는 코드들이 여기저기 흩어져 있고
- 정확히 어떤 부분을 수정해야 하는지 알기 어렵다.
- 기능별로 나누기 어렵다.
- 테스트 케이스별로 나눠도 코드가 겹친다.
이런 문제 때문에 기능,혹은 케이스별로 브렌치를 나누지 않기로 했습니다.
대신, 개인 브렌치를 생성해서 유지하고 develop 의 최신 커밋이력을 각개인 브렌치로 pull 하는 방식을 사용하기로 했습니다.
즉 이런식으로 말이죠
맨 위의 dev1 ,dev2, dev3 branch 는 각각 develop 의 최신 커밋이력을 받아서 사용하려고 했습니다.
squsah-merge 와 rebase 를 이용해서요.
squsah-merge 는 현재 브렌치의 커밋이력을 하나로 합쳐서 커밋이력을 깔끔하게 만들 수 있다. 라는 어줍잖은 지식만 가지고
"헤헤, 그럼 우리 squsah-merge 쓰자!" 했습니다... 크게 문제가 될 지 모르구요.
또.. rebase 는 "현재 브렌치를 타겟 브렌치의 커밋이력을 모두 가져와준대" 라는 가벼운 생각만 가지구요..
그럼 squsah-merge 로는 내 코드를 develop branch 에 머지하고 rebase 로는 develop branch 의 최신 변경사항을 가져오기로 했습니다.
그리고...
이 거짓말쟁이의 말을... 덥석 믿어버렸기 때문입니다. claude-4-sonnet 이 자식아..
발생한 문제
그렇게 첫 squash-merge 는 이상없이 진행되었습니다.
그런데 이상한 문제가 발생합니다.
git 작성내용은 다음과 같습니다.
- git add .
- git commit -m "[ feat ] 기능 구현"
- git push origin '내 브렌치'
- 깃허브 홈페이지 "[ 내 브렌치 ] -> [ develop ]" pr 생성
- 충돌 확인후 squash-merge
- [ 내 브렌치 ] 에서 git rebase develop
- 재 작업
- git add .
- git commit -m "[ feat ] 두번째 기능 구현"
- git push origin '내 브렌치'
- 깃허브 홈페이지 "[ 내 브렌치 ] -> [ develop ]" pr 생성
- pr 생성이 이전 커밋내역까지 포함됨
저 뿐만 아니라 다른 모두가 pr 을 생성할 때마다, 개인이 작업했던 브렌치에서 이전에 이미 push 했던 작업 내역까지 모두 포함되는 겁니다.
이대로는 모든 커밋내역이 pr 하나를 생성할때마다 전부 반영되게 생겼습니다.
그래서 대체 왜 이렇게 되는건지 하나하나 차근 따져봤습니다.
squash-merge 의 동작방식
squash-merge 는 현재 브렌치에서 target branch 로 커밋 이력을 모두 하나로 합쳐서 가장 앞에 배치합니다.
dev/name 에는 commit1 에서 파생된 commit1-1과 commit1-2 가 있었는데
그 내역을 모두 합쳐서 commit-4 라는 새로운 내역을 만들어서
develop 브렌치의 가장 앞으로 배치해줬습니다.
여기까지 진행되었을 때, 우리는 이렇게 생각했습니다.
commit1 에서 commit 1-1로 연결된 부분을 해제하고
commit4에서 commit 1-1로 연결해주면 해결 아닌가...?
물론 아니었습니다.
rebase의 동작 방식
git rebase 는 "현재 커밋이력을 그대로 유지한채로 가장 앞에 배치합니다.
❗️❗️그리고 그 과정에서 git log 의 hash 값을 모두 바꿉니다❗️❗️
이건 무슨 말이냐면 git hub 는 커밋을 해쉬값으로 구분합니다.
빨간 줄을 친 부분들이 모두 git hub가 커밋마다 가지고 있는 고유한 해쉬값인데요.
이 여부로 해당 커밋이 merge가 되었는지 안되었는지 파악합니다.
근데 rebase 를 하게 되면서 당연하게도 이전 commit 들이 모두 해쉬값이 바뀌었기 때문에, commit 이 된적이 없다고 판단 똑같은 커밋 내역이 계속 pr 내역에 올라가게 되었습니다.
squash-merge + rebase 조합으로는 절대!!!!로!!! 브렌치를 유지하면서 작업을 할수가 없는데 왜 나한테 된다고했어!! claude 개자식아!!!!!!!
squash-merge 는 언제 사용할까?
결국 squash-merge 를 자세히 살펴보면
커밋 내역이 공유되지 않는다는것 을 알 수 있어요.
자신의 커밋내역을 모두 합해서 target branch의 커밋내역 가장 앞에 생성해줄 뿐이니까요.
그래서 보통 squash-merge는
- 기능 단위 작업후 해당 branch를 삭제할 경우
사용하는게 best-practice 입니다.
저희가 하려고 했던 branch를 유지하면서 작업하기 와는 어울리지 않는 방식이었어요.
돌고돌아 순정..
그래서 결국 저희는 일반 3-way-merge를 사용하기로 했습니다.
커밋히스토리를 깔끔하게 유지할수는 없어졌지만, 그래도 하나의 브렌치를 계속 유지하면서 작업을 하고 싶다는 목적은 달성할 수 있었어요.
마무리
같은 조원인 신우진 행님, 조우디와 같이 깃허브 관련 문제를 2시간 정도 들여다보면서
git hub 관한 지식이 훨씬 늘어서 너무 좋은 시간이었습니다.
회사가서 이런일 겪었으면 너무 부끄러웠을 거잖아요.
여러분도 브렌치사용전략에 맞춰서 깃허브 명령어를 잘 사용하시길 바라겠습니다.
