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 을 참고하시기 바랍니다.
좋은 글 잘 읽었습니다. SVN만 써보고 Git을 한 번도 안써봤는데... 제대로 써봐야겠네요 ㅎㅎ
답글삭제댓글 고맙다.
삭제이 블로그는 내가 개발하면서 느꼈던 유용한 내용들을 정리해 나가려는 목적으로 만들었다. 더불어 내게 유용한 내용이라면 다른 사람에게도 도움이 되지 않을까 싶기도 하고...
종종 좋은 글을 올릴 테니 한달에 한두번 정도는 찾아와 주기 바란다 ㅎㅎ
그동안 헤맸던 내용을 알기 쉽게 알려주셔서 감사합니다/
답글삭제댓글 감사합니다. ^^
삭제감사합니다. 일하면서 SVN을 사용하다가 git을 혼자 공부하려고 했는데 이해하는데 많은 도움이 되었습니다.
답글삭제git 말로만들었었는데 정리가 딱되네요! 특히 svn과 비교점두요
답글삭제좋은글 감사합니다
궁금한 내용이었는데 도움이 됐습니다.
답글삭제감사합니다.
좋은 글 잘 참고하고 갑니다!
답글삭제좋은 글 잘 참고하고 갑니다!
답글삭제당신같은 사람들 때문에 제가 살아갑니다. ㅠㅠ
답글삭제유용한 개념설명 너무 감사합니다.
그런데 이클립스에 로컬 히스토리가 있는데 또 필요한가요?
답글삭제왜 필요한지 모르겠습니다.
이클립스 쓰는 사람만 깃을 쓰는게 아니니까요..
삭제앞으로 평생 이클립스만 쓰게 될까요..?
정리글 감사합니다^^; 저는 svn만 사용해 왔는데 궁금한게 있습니다.
답글삭제git의 장점으로 개발자가 자신만의 commit history를 가질 수 있다고 하셨는데..
svn을 사용자들이 개인 유저로 되어 있으면 유저별 commit history를 가질수 있지 않나요?
svn과 git의 차이를 정확히 집어주셨네요.
답글삭제그러나 조직들으 svn을 사용하는 이유는 git이 어렵다기 보다,
git이 공개형 프로젝트라 그렇습니다.
비공개로 돌리려면 과금해야하는걸로 알고있어요
공개되는 프로젝트는 깃허브같은 사이트를 서버로 사용해서 그런거 아닌가요? 보통 사이트 나가면 깃서버를 회사 내부에 구성하고 진행해서 그런 일은 본적이 없는 것 같습니다. 그리고 깃은 저장소 자체가 분산되어 있어서 네트워크가 끊기거나 서버가 파괴되도 다른 수많은 저장소를 이용해 복구 할 수 있고 스테이지와 스태쉬를 이용해 수정한 파일을 커밋 대상에서 제외시킬 수도 있고 스냅샷을 이용해 브랜치를 쉽게 만들 수 있기 때문에 굉장히 안정적입니다. 태그나 리베이스 같은 좋은 기능은 덤이구요. 사실 svn은 과거의 유물이고 전부 dvcs로 가는게 맞는 기초가 되는 개념이 워낙에 다르다보니 어렵게 느껴져서 안쓰는게 한 몫하는것 같습니다. 물론 영어권 국가가 아니기 때문에 기술 확산 속도가 늦은 것도 또 다른 이유가 되겠죠.
삭제..? 왠 과금...
삭제위에 익명이가 말한 기능은 svn 으로도 충분히 가능한데 깃 추종자들은 머리가 어떻게 됐나... 있는 것도 제대로 못 쓰는 것들이 무슨 과거의 유물이라고 무시나 하고... 쯔쯔.
삭제git의 문제는 뭐 좀 하려고만 하면 head를 못찾는다는 오류 너무 잦다.
답글삭제개발자는 마음대로 commit하다가 자신이 원하는 순간에 서버에 변경 내역(commit history)을 보낼 수 있으며, 서버의 통합 관리자는 관리자가 원하는 순간에 각 개발자의 commit history를 가져올 수 있습니다.
답글삭제라는 걸 왜 여기저기서 장점으로 적어두는지 모르겠군요. 깃의 커밋은 svn 의 commit 과는 엄연히 다른 결국 로컬에 save 하는 것과 마찬가지인 기능인데 깃의 commit 은 다른 개발자에게 영향을 끼치지 않는다? 애초에 개념 자체가 틀렸네요.
결국 서버에 올리는 시점에서 다른 개발자에게 영향을 끼칠 수 있는 것은 svn 이나 git 이나 똑같은데 왜 이걸 다르게 보는지 모르겠습니다.