10주차
10주차 핀토스 유저 프로그램 주차에 들어서면서 팀원들과 협력에 대해 얘기했다.
9주차에는 이야기를 나눈 후 각자 알아서 진행
각자도생 느낌이였다면
10주차에는 "협력 좀 하자" 이런 느낌으로 진행하기로 했다.
협력이란...
아니
git push origin dev/woody
이렇게 remote로 push 할 때마다 왜 똑같은 commit들이 중복되는건데?
분명 내가 먼저 push 이후 merge 실행
근데 전에 merge 했던 이력들이 계속 반복됨??????????
어? 이상하네?
우리가 생각했던 git log
그리고 이후에 main에 merge하는 느낌으로 생각했다.
현실은
깃 브랜치들도 마치 저번주의 우리처럼 각자도생 하는 느낌이였다.
왜냐하면, 우리는 squash-merge와 rebase를 사용했다. (잘 모른 상태로)
왜 squash-merge와 rebase and merge를 사용하려고 했는가?
음...git repository를 생성해 준 팀원 yangOO씨가
Squash and merge를 default로 설정해 두었다.
나도 작업을 하면서 무의식적으로 확인하지 않고 pull request 버튼을 눌러 버린 것.
그래서 이미 merge된 파일임에도 불구하고, 둘의 기능도 제대로 모르고
squash and merge 후 rebase를 해버리니, 이렇게 발생한 듯 하다.
둘이 뭐가 다른가?
squash and merge
main: A---B---M1 ← squash된 커밋
A: \---C1---C2---C3
3개의 커밋이 있을때, 이들을 합쳐서 merge하는 방식
장점
- 간결함
- 롤백 간편
단점
- 상세 커밋 기록 사라짐
장점은 간결해지기 때문에 복잡성이 사라지는 큰 장점을 갖고 있지만, 그게 단점이기도 하다.
이전 커밋 이력들도 사라져 히스토리 관리에는 좀 어려운 느낌인거 같다.
rebase and merge
3개의 커밋이 있을 때, 3개의 커밋을 유지한채로 merge하는 방식
장점
- 변경 추적이 용이하다.
- 순차적 충돌 해결 가능
- 커밋 단위로 리뷰 가능
단점
- 여러 커밋이라면 롤백이 복잡할 수 있음
솔직히 squash and merge, rebase and merge를 정확하게 이해를 하진 못한듯 하다.
하지만, 왜? why? 현재 우리 조에서 사용하면 안되는지 알게 되었다.
그 이유는
현재 우리가 하려는 구조는 기능 단위 브랜치가 아니기 때문이다.
우리 조에서 추구하는 방식은 각자의 브랜치를 지속적으로 이어나가는 방식인 3-way merge 방식이 더 적합하다 생각하였다.
기능 단위 브랜치일 때 squash and merge, rebase and merge를 이용한다면 분명 깔끔한 커밋 히스토리과 복잡성을 크게 줄여줄 것이다.
결론 우리에게는 맞지 않음.
3-way merge로 가자.
