📌 Git Conflit는 초면이라...
???: 저희 코드 충돌날 일 없게 8인 페어를 하는 건 어떨까요?
레벨1과 2에는 pull, add, commit, push 네 개의 명령어만으로도 무리 없이 살아남을 수 있었기에, 깃허브 공부는 사치라고 여겼다.
레벨3에서는 여덟 명의 크루가 모여서 코드를 작성하기에, 코드 충돌이 빈번하게 발생했다. 이런 충돌 해결에 어려움을 겪고, 팀원 간 브랜치 전략에 대한 논의가 계속되자 더 이상 협업 툴에 대한 학습을 미룰 수 없다는 것을 깨닫게 되었다.
📌 Git 브랜치 전략
초반부터 브랜치 전략에 대한 언급은 있었다. 프로젝트 경험이 없는 경우에는 생소할 수 있는 개념이라 각자 공부할 시간을 조금 가지고, 기획에 대한 틀이 어느 정도 갖춰진 후에야 회의를 진행하게 되었다.
Git Flow랑 Github Flow에 대한 테코톡 영상도 보고, 블로그 글도 열심히 읽었다만, feature를 제외한 hotfix, release와 같은 브랜치들은 너무 먼 이야기 같아서 잘 와닿지 않았다. 브랜치 전략을 지키면서 개발을 한 경험이 부족해서 그랬던 걸지도 모르겠다.
팀원들과의 토론 끝에 우선은 feature 브랜치와 develop 브랜치만 두고, feature에서 기능 구현이 끝나면 develop으로 병합하는 방식을 채택했다. 그러나 금요일에 있었던 미션에서 배포와 개발에서 다른 버전의 코드를 관리하고, 갑작스러운 버그가 발생하는 등의 시나리오가 주어짐에 따라 다음과 같은 브랜치 정책을 사용하게 되었다.
📌 브랜치를 합치는 방법
리드미 파일만을 가지는 깃허브 Repository를 생성하고 main 브랜치에서는 MAIN.md 파일을, feature 브랜치에서는 POTATO.md 파일을 추가하면 다음과 같이 분기가 발생한다.
1. merge 명령어 사용
merge 명령어를 실행하면, 다음과 같이 해당 브랜치로 병합을 실행하고 새로운 커밋 이력을 생성한다.
2. rebase 명령어 사용
반면 rebase 명령어를 실행하면, 특정 브랜치를 base로 커밋 이력을 다시 정렬을 수행하기 때문에 main의 커밋이 먼저 적용되고 feature의 변경 사항이 반영된다. merge 방식에 비해 브랜치 변경 이력이 하나의 플로우로 간결하게 보인다는 장점이 있다.
새롭게 정렬되는 commit 이력은 이전과 다른 ID를 가지게 되기 때문에, main에서 다른 브랜치를 기준으로 rebase를 수행하지 않는 것이 좋다.
📌 충돌을 해결하는 방법
혼자 모든 코드를 작성한다.
feature와 main에서 동시에 README.md에 변경 사항을 추가하면 병합 수행 시 다음과 같이 충돌이 발생한다. HEAD 부분이 현재 작업 중인 feature의 버전이고, 구분선 아래 텍스트가 main에서 작성된 버전이다.
1. merge 충돌 해결
아까와 동일하게 merge 명령어를 수행했지만, 이번에는 충돌이 발생하기 때문에 충돌을 바로잡고 결과물을 커밋하라는 내용이 표시된다.
에디터를 이용해 README.md 파일을 수정하고 commit을 하면 다음과 같이 충돌 해결 이력과 함께 병합이 이루어진다.
2. rebase 충돌 해결
rebase 시 충돌이 발생하는 경우에는 해당 명령어에 대해 수행 가능한 여러 옵션에 대한 설명이 표시된다. abort를 하는 경우에는 rebase 명령어를 수행하기 전으로 되돌릴 수 있다.
merge 충돌 해결과 마찬가지로 모든 충돌을 해결하고 rebase --continue를 입력하면 병합이 완료되어 다음과 같은 결과를 얻게 된다.
📌 Merge VS Rebase
rebase를 사용하는 경우 불필요한 병합 커밋이 발생하지 않아 커밋 히스토리가 더 간결하고, rebase를 통해 커밋의 순서를 원하는대로 조정할 수 있다는 장점이 있다. merge의 경우 분기 내역이 유지되어 브랜치 간의 관계를 쉽게 파악할 수 있으며, 커밋 내역을 변경하지 않으므로 실수를 되돌리기 쉽다.
우리 팀은 처음에 rebase and merge 방식으로 주요 브랜치에 변경 사항을 반영하려 했으나, 공유 브랜치에서 rebase 사용 시 문제가 발생하기 쉽고, 커밋 내역이 변경될 위험이 존재하며, 무엇보다 사용이 어렵다는 단점이 크게 다가왔다. 이에 따라 rebase의 장점인 커밋 히스토리 정리와 merge의 장점인 안전성을 모두 가진 squash and merge 방식을 새롭게 채택했다.
등 떠밀려 merge와 rebase에 대해 알아봤지만, 제대로 이해하고 있는 편이 프로젝트 진행에 도움이 많이 될 것 같다 🍟 🍟