팀을 SVN에서 Git으로 옮기며 정한 것들

그동안 SVN을 썼는데 Git으로 옮기게 됐다. 옮기는 것 자체는 하루면 됐고 오래 걸린 것은 어떻게 쓸지 정하는 것이었다.

Open Table of contents

배경 — 무엇이 달라지나

먼저 팀에 설명해야 했는데 명령어가 다르다는 것보다 생각하는 방식이 다르다는 것이 중요했다.

넷 중에 branch 가 가벼워지는 것이 실제 작업을 가장 크게 바꿨다.

SVN에서는 svn copy 로 서버에 복사본을 만드는 일이라 자주 하지 않았다. Git에서는 거의 공짜라 마음대로 만들 수 있는데 그러자 언제 만들고 언제 합칠지가 새로운 결정 거리가 됐다.

가장 크게 와닿은 것은 커밋이 곧 공유가 아니라는 점이었다.

SVN에서는 commit 하면 바로 다른 사람에게 보이므로 완성된 것만 올리는 습관이 있었다. Git에서는 내 쪽에 먼저 쌓고 push 로 보내니 중간 단계도 commit 할 수 있다.

이것이 익숙해지는 데 몇 주 걸렸다. 습관이 도구를 따라 바뀌는 데 걸리는 시간이 도구를 옮기는 시간보다 길었다.

여기가 제일 오래 걸렸다. 알려진 방식이 몇 가지 있어서 그대로 따를까 했다.

master   — 지금 운영에 올라간 것
develop  — 다음 배포에 들어갈 것
feature/ — 작업 중인 것 (develop에서 갈라져 develop으로)
hotfix/  — 급한 수정 (master에서 갈라져 master와 develop 양쪽으로)

master 와 develop 과 feature/ 와 hotfix/ 넷으로 정했다.

처음에는 더 넣을까 했는데 규칙이 많으면 안 지킨다는 것을 알아서 줄였다. 지켜지지 않는 규칙은 없는 것과 같고 안 지켜지는 것이 하나 생기면 나머지도 느슨해진다.

그대로 따라 하려다가 전제가 우리와 안 맞는 부분이 보였다.

배포가 자주 있는 팀을 전제 — 우리는 2주에 한 번
여러 버전을 동시에 유지하는 것을 전제 — 우리는 최신 하나만
브랜치 종류가 다섯 가지 — 팀이 다섯 명이라 과하다

셋 다 그 방식이 나쁘다는 뜻이 아니라 우리 조건이 다르다는 뜻이었다.

전제가 안 맞는 방식을 그대로 가져오면 규칙만 남고 그 규칙이 왜 있는지가 사라진다. 그러면 지키는 사람도 왜 지키는지 모르게 된다.

정하고 나서 부딪힌 것이 셋이었다.

각자 작업하다 merge 하면 갈라졌다 만난 자국이 남아 이력이 지저분해졌다. 왜 이렇게 됐는지 찾을 때 읽기가 어려워서 feature/ 는 합치기 전에 최신 develop 위로 rebase 하기로 했다.

여기에는 조건을 붙였다. 이미 push 한 것에는 rebase 를 쓰면 안 되는데 남이 받아 간 것을 바꾸면 그쪽이 꼬이기 때문이다.

commit 메시지도 SVN 때처럼 한 줄로 쓰다가 git log 를 볼 때 아무것도 알 수 없다는 것을 느꼈다.

첫 줄: 무엇을 했는지 (50자 이내)
빈 줄
본문: 왜 그렇게 했는지

왜를 쓰는 것이 핵심이라고 봤다. 무엇을 했는지는 코드를 보면 알지만 왜 그랬는지는 코드에 안 남는다.

충돌을 무서워하는 반응도 있었다. SVN에서 고생한 기억 때문인데 Git이라고 충돌이 없는 것은 아니다.

작업 브랜치를 오래 두지 않는다. 길어도 사흘
매일 아침 develop을 받아 온다
한 파일을 여러 명이 고치는 작업은 순서를 정한다

충돌은 develop 에서 오래 갈라져 있을수록 커진다. 이것을 알고 나서는 자주 합치는 쪽으로 습관이 바뀌었다.

몇 가지는 아직 답을 못 냈다.

코드 리뷰를 합치기 전에 보는 것이 맞아 보이는데 그러면 기다리는 시간이 생긴다. 지금은 합친 뒤에 보고 있고 그러면 이미 들어간 것을 고치는 일이 된다.

tag 는 배포할 때 붙이자고 했는데 실제로는 잊고 안 붙인다. 사람이 기억해야 하는 절차는 결국 빠지므로 자동으로 붙이는 방법을 찾아야겠다.

되돌리는 방법이 여러 가지인 것도 아직 헷갈린다. 이력을 남기고 되돌리는 것과 아예 없애는 것이 있는데 언제 무엇을 쓸지 몰라서 지금은 안전한 쪽만 쓰고 있다.