git을 사용하면서 스스로에게 다음과 같은 질문을 할 때가 많았습니다.
- git이 svn 대비 장점은 무엇일까?
- 왜 많은 조직들이 svn에서 git으로 옮기려고 하는가?
그런데, 많은 open source projects 들이 git을 사용하고 있고, 소위 잘나가는 개발사들은 git을 기반으로한 source control을 사용합니다. 거기에는 나름의 이유가 있고, 그 이유를 정확히 알아야 우리가 각 project에 최적인 방법으로 source를 운용할 수 있습니다. 우리가 원하는 것은 결국 소스를 최신으로 유지하면서도 개발자들이 원하는대로 원하는 순간에 수정할 수 있는 방법을 찾는 것이고, 이를 달성하기 위해서는 분산 관리 방식의 장점을 정확히 이해하는 것부터 시작해야 할 것입니다.
svn으로 작업할 때에는 소스를 중앙 저장소에 commit 하기 전에 대부분의 기능을 완성해놓고 commit 하는 경우가 많습니다. 그도 그럴 것이, commit을 한다는 자체가 중앙 저장소에 내가 만든 기능을 공개한다는 뜻이기 때문입니다. 그래서 개발자가 자신만의 version history를 가질 수 없고, commit한 내용에 실수가 있을 시에 다른 개발자에게 바로 영향을 미치게 됩니다. ( 물론, branch를 따서 관리하는 방법도 있지만, 수백명의 개발자의 branch를 따로 만들어주고 관리하는 것은 굉장히 어렵습니다. )
반면, git은 개발자가 자신만의 commit history를 가질 수 있고, 개발자와 서버의 저장소는 독립적으로 관리 가능합니다. 여기서 독립적으로 관리한다는 말은 개발자의 commit이 바로 서버에 영향을 미치지 않는다는 것입니다. 개발자는 마음대로 commit하다가 자신이 원하는 순간에 서버에 변경 내역(commit history)을 보낼 수 있으며, 서버의 통합 관리자는 관리자가 원하는 순간에 각 개발자의 commit history를 가져올 수 있습니다.
통합 관리자가 각 개발자의 commit history를 가져온다는 것은, 각 개발자가 완성한 commit histroy에 대해서 통합 관리자가 차후에 아무때나 가져와 적용할 수 있다는 뜻입니다. 통합 관리자가 각 개발자의 commit history를 가져오기 전에 이미 각 개발자는 자신의 저장소와 서버의 저장소간 통합을 마친 상태이므로 통합 관리자는 별다른 어려움 없이 commit history를 가져올 수 있습니다. ( 여기서 별다른 어려움이 없다는 말은 merge conflicts가 일어나지 않는다는 말입니다. 다른 말로 Fast forward merge 라고 합니다. 클릭하면 커지는 아래 그림 참조. )
따라서 svn과 다르게 git은 굉장히 다양한 방식으로 소스를 관리할 수 있으며, open source projects에서 많이 사용하는 방법들에는 다음과 같은 것들이 있습니다.
위 방식들에 대한 자세한 내용은 http://git-scm.com/book 을 참고하시기 바랍니다.
