github repo 관리 고민

이전 github Rebase and Merge를 사용하지 말자에서 github의 Rebase and Merge로 고생한 경험을 바탕으로 나만의 결론을 내렸다.

github의 Rebase and Merge는 git의 Rebase와 다르게 동작하며, 양 branch의 commit history가 독립적으로 유지된다. 따라서 삭제하지 않을 branch 간의 통합에 Rebase and Merge를 사용해서는 안 된다. 그러므로 Squash and merge를 대신 사용하겠다.

그 글을 읽은 사람은 아마도 꽤 당황했을 것이다.

어설픈 결론의 배경

git-flow를 유지하면서 깔끔한 linear history를 만들고 싶었다. feature > dev 통합은 Rebase and Merge를 사용하고 dev > master는 Merge를 사용하는게 가장 적절하지만, 상황에 따라 다른 두 방법을 선택하는 건 실수의 여지가 있다. 찾아보면 branch name pattern에 맞춰 통합 방법을 강제하는 방법이 있을지 모르겠지만, 복잡한 설정을 하고 싶지 않았다. Squash and Merge를 사용하면 둘의 장점만을 끌어와 Merge에 비해 깨끗한 history와, Rebase ans Merge와 달리 양 branch의 merge commit이 생성되므로 안성맞춤이라 생각했다.

사고(?) 재발

당초 A-ToDo는 사용자 회원가입 기능 없이 우선 개발하고, 직접 사용하며 기능을 개선하다가 사용자 회원가입 기능을 추가할 계획이었다. 첫 사고는 회원가입 기능을 제외한 나머지 모든 기능을 마무리하고 dev > master 통합 때 발생했다. 이후, github의 Rebase and Merge가 git과 다르게 동작한단 사실을 파악하고 Squash and Merge를 도입했다.

이후 회원가입 기능을 구현하기 시작했다. 여기서 문제는 회원가입을 구현하며 DB Schema를 다시 설계하면서 major versioning을 고민할 정도로 프로그램 내부구조가 크게 바뀌었다는 것이다. dev > master로의 통합 주기가 매우 길어지면서 Squash and Merge의 작동 방식이 Rebase and Merge와 같이 통합될 두 branch의 독립적 history를 보장한단 사실을 너무 늦게 깨달았다.

branch rule에 linear history를 켜놨는데도, repo setting에서 Squash and Merge만 활성화해도 괜찮았던 순간에 눈치채야 했다...

dependency 파일이긴 하지만, 한 파일에만 conflict이 81개가 있는 건 처음 봤다...

되짚어볼 결론

github repo를 관리할 때, dev > main, main > dev와 같이 통합할 양 branch를 유지한다면 Rebase and Merge나 Squash and Merge를 사용해선 안 된다. 반대로 feature > dev나 hotfix > master 처럼 통합 후 삭제할 branch라면 Merge보단 Rebase and Merge나 Squash and Merge를 사용하는게 더 깨끗한 git tree를 만든다.

git의 동작과 다르게 동작하는 건 아마 원격 저장소의 git tree가 변경되면 발생할 다른 local repo와의 동기화 문제를 고려해서가 아닐까?

그냥 github-flow로 갈아탈까?

어차피 혼자 하는 프로젝트인데 git flow가 적합해 보이지도 않고, 괜히 두 가지의 통합을 사용하다 실수하면 revert 하기도 귀찮고... 아무래도 A-ToDo-Client는 github-flow로 갈아타야겠다.

그래도 이번 시도는 좋은 경험이었다. A-ToDo-Server는 github-flow(trunk-based)로, Client는 git-flow로 운영해 보며 두 방법의 장단을 조금이나마 느껴볼 수 있었다.

특히, DB schema 변경에 따라 통합 주기가 길어지면서 trunk-based의 단점이 부각됐다. 의미 있는 history는 commit node을 잘 만드는 것만큼이나 branch를 작게, 적절한 이름으로 가져가는 것도 중요하다. 이번 사례처럼 통합 주기를 길게 가져가야 하는 개발 환경이라면, trunk base는 불가능해 보인다.

repo 관리에 옳은 방법은 없다. 하지만 프로젝트마다 더 적절한 방법은 있다.