실제론 svn으로 버젼관리를 하는 상황에서, git을 그 위에 쓰다보니 몇 가지 문제를 겪어야 했다.사실 몇 가지 점에서 git 의 동작을(혹은 git-svn의 동작을) 이해할 수가 없었는데, 최근에 Pragmatic Version Control using Git 을 구입해서 읽고나니 약간은 이해할 수 있게 되었다.
svn은 본질적으로 선형적인(linear) 이력(history) 를 갖는다. 즉,
- 최초의 repository 상태가 있고,
- 이 위에 새로운 변경 rev 2
- 그 위에 새로운 변경이 더해져 rev 3
- …
- 마지막 변경이 가해져서 rev n
이 되는 형태다.
반대로 git은 각 개별 repository(DVCS니까)가 브랜치처럼 인지되고 / 변경 사항이 merge 되는 것 처럼 동작한다. 이에 따라 svn update에 대응되는 git 동작은 git pull이 아니라 git svn rebase (사실상은 git rebase) 만 가능해던 거다. 선형 이력이 아니라 브랜치간 merge 이력인 git이 svn 쪽에는 정상적인 svn 복사본인양 보여야하기에 이런 추가 동작을 해야하는 것.
그리고 rebase 이기 때문에 커밋되지 않은 변경사항이 있으면 안되던 것 — 보통 git stash로 잠시 패치를 만들어 빼둔다 — 도 이해가 가게 되었다; svn update는 로컬에 변경사항이 있다면 묵시적인 머지를 시도하는 거지만, git의 경우엔 그런 머지를 git의 관점에서 추적할 수단이 없기에.
개인적인 해결책(?)은 그냥 svn 브랜치 / 개발 브랜치 따로 쓰면서 git svn을 쓰는게 답이 아닐까 싶지만 그럼 git svn이 복잡하기도 하고 merge/fast-forward 가 난무하게 되는 것도 사용자 입장에선 꽤나 귀찮은 일이 될테니 역시 이것도 답이 없나?
결국 git-svn의 동작이 이해안가고 / 맘에 안들던 이유는 git과 svn의 이력관리의 차이…때문인듯하다;
ps. 여튼 책을 읽으면서 커밋되지 않은 변경 사항이 branch 딸 때 어떻게 된다거나 / 써보지 않은 signing이나 k-merge 전략 같은 내용도 개념을 잡게 해줬다는 점에서는 괜찮았다. 그렇지만 책 자체가 튜토리얼치곤 양이 많고 / 리퍼런스치곤 볼륨이 부족하다는 점은 좀 아쉬비;