2011년 10월 25일 화요일

SVN보다 Git가 더 좋을까?

요즘 SVN을 써야하나 Git를 써야하나? 또는 Mercurial을 써야하는 사람들이 많이 눈에 띈다.
또 누구는 아직도 ClearCase를 선호하고 Perforce가 좋다는 사람도 있고 혼란스럽기 그지 없다.
마치 골프를 치는데 골프채 뭐가 좋다고 서로 주장하는 것과도 같다. 아무리 좋은 골프채도 몸에 맞지 않으면 무용지물이다.

그럼 이런 애매한 것들을 깨끗하게 정의해 주겠다. ^^ 애정남 처럼

결론부터 말하면 다음과 같다.

  1. 분산된 환경에서 일을 하는 경우가 잦다면 Git를 써라.
  2. Github를 써야 한다면 Git를 써라.
  3. 그외에는 모두 SVN을 써라.
기타 의견)
혼자 개발한다면 내키는 것을 써라.
회사에서 강제를 한다면 시키는대로 해라.
다른 툴에 완전히 익어서 바꾸기 싫으면 마음대로 해라.

기존에 VSS를 쓰던 사람들은 CVS를 써보면 신천지 였다. 
CVS를 쓰던 사람들에게 SVN은 놀라움 그 자체였다.

그럼 Git는 어떨까? 
일단 소스코드관리시스템에 대해서 좀 알 필요가 있다.

소스코드관리시스템은 크게 3종류로 나눌 수 있다.
  • Folder공유 타입 - RCS, SCCS
  • Client/Server 타입 - Subversion(SVN), CVS, Perforce, ClearCase, TFS
  • 분산 저장소 타입 - Git, Mercurial, Bitkeeper, SVK, Darcs
폴더공유타입은 써보신 분이 있을지 모르겠지만 그래도 옛날에는 훌륭했다.C/S타입과 분산타입의 가장 큰 차이는 Repository가 중앙에 하나가 있나, 분산되어 여러개가 있나이다.

SVN과 Git는 1:1로 비교하기는 어렵다. 형태가 다르고 장단점이 있을 뿐이다.

물론 SVN을 가지고 하던 것은 Git로 거의 다 된다.
또한 SVN에서 안되던 것도 Git에서 되는 것도 많다.

그러면 Git가 SVN보다 좋은 것인가?

SVN에서 제공하지 않지만 Git에서 제공하는 기능이 꼭 필요한 경우라면 Git를 쓰는 것이 유리할 수 있다.
  • Offline에서 자주 개발을 해야 할 때
  • Git 기반의 Open source를 이용한 개발을 해야 할 때
  • Git 기반의 Open source 프로젝트에 참여할 때
  • Github을 써야 할 때
이런 경우가 아니라면 SVN을 쓰는 것도 좋다. SVN가지고 안되는 것이 있다거나 불편하다고 생각하는 사람들은 SVN의 막강한 기능을 극히 일부만 쓰고 있어서 그럴 수 있다.

Git는 기본적으로 SVN보다 복잡하다. Git는 명령어가 SVN보다 몇배 많다. 컨셉을 배우기도 복잡하다.
SVN을 쓰는 회사에서도 대부분의 개발자들은 SVN의 기능도 극히 일부만 쓰고 있다. 그런 상황에서 Git는 배우기 훨씬 어렵다. 따라서 Git 특유의 기능이 필요하지도 않는 상황이면 SVN이 더 낫다.

Git를 잘 모르고 쓰면 혼란이 가중될 수 있다. 소스코드 Conflict가 자주 일어날 수 있다.
공부도 훨씬 많이 해야 하며 전략을 잘 짜야 한다. 

물론 혼자서 또는 두세명이 개발을 하고 있다면 뭘 써도 별로 혼란스러울 것이 없지만, 수십명 또는 수백명의 개발자가 동시에 일하는 환경이라면 Git는 좀더 정교해야 한다.

Git는 브랜치 머지가 더 손쉽고 Local에서 일하는 것에 대한 자유도가 훨씬 높다. 하지만 이러한 장점들이 Git를 쉽게 쓸 수 있게 해주지는 않는다.
SVN과 Git는 누가 더 좋은 것이라고 비교하기 어려운 것이니 엄마가 좋아? 아빠가 좋아? 고민은 하지 말자. 

하지만 이 블로그를 읽은 정도의 개발자라면 개인적으로 SVN뿐만 아니라 Git에 대해서도 빠삭하게 알고 남들이 물어볼때 조언을 해 줄 정도는 되어야 할 것 같다. ^^

2020년 7월에 추가한 내용


이 글을 작성한지 9년이 지났다. 그래서 주변 환경이 많이 바뀐만큼 결정의 기준도 바뀌었다. 9년 전인 2011년에는 git를 쉽게 지원하는 client도 시원치 않았다. 하지만 지금까지 많은 기술의 변화가 있었다. 그래서 SVN을 쓸지 Git을 쓸지 결론을 말하지만 다음과 같다.

  • 회사에서 이미 SVN을 쓰고 있어서 Git으로 마이그레이션이 어렵다면 SVN을 써라.
  • 발주사에서 SVN을 써야 한다고 하면 SVN을 써라.
  • 그외에는 모두 Git을 써라.
    • 회사를 새로 시작한다면 Git을 써라.
    • SVN을 쓰고 있어도 Git으로 마이그레이션을 하고 싶으면 해라.
    • SVN에서 Git으로 바뀐다면 Repository 전략을 바꾸어야 한다.

추가 의견으로 Git을 쓴다면 Cloud 서비스를 이용하는 것을 권장한다. 서버를 직접 관리하는 것보다 시간, 비용면에서 효율적이다. Github, GitLab, Bitbucket, Azure Repos 등이 있다.

같은 조건이라면 Git을 사용하기를 권장하지만, SVN을 사용한다고 큰 문제가 있는 것이 아니다. SVN을 잘 쓰고 있다면 계속 사용해도 문제가 없고, 시간과 비용을 들여서 Git으로 옮겨가고 싶다면, 시도해볼만 하다.



    댓글 42개:

    1. 헐.....
      마지막 문장에서... 좌절했습니다.
      :(

      열심히 보고는 있지만 (항상 좋은 글 감사합니다.)... 설명해줘라? 조언??
      -_-;;

      그냥 개발자 안할래요 :( ...

      -마음가는 길은 곧은 길-

      답글삭제
    2. 최근 고민 중의 하나 였는데, 애정남처럼 깔끔히 정리를 해주시네요.^^
      저는 Git에 해당되지 않아서 SVN에 더 많은 애정을 줘야 겠습니다.

      답글삭제
    3. mercurial은 왜 버리시나요 -_-;;;
      mercurial도 쓰기 편한데.
      구글링을 해보면 git vs. mercurial에 대한 비교 논쟁은 쓸데없는 일이라고 하네요. 그냥 닥치고(?) 하나 골라서 열심히 쓰라고.

      http://gitvsmercurial.com/ 대문에 적힌 글입니다. 좀 과격하지만 맞는 말인 듯하네요. :-)

      "Who the FUCK cares?

      Use what YOU like, not what someone on the internet tells you to."

      답글삭제
    4. 좋은 글이네요.
      Git은 막강한 만큼 배우는데 비용이 많이 들더라구요.
      Android 같이 방대한 코드를 모듈화해서 관리할 때도 Git이 좋은 것 같습니다.
      Repo라는 툴이 있으니까요..

      답글삭제
    5. git이 배우기 어려운건 기능이 많기 때문입니다. svn처럼만 사용한다면 그리 어렵지 않습니다. 중앙 저장소 두고 중앙 관리자 두고 pull, push(svn의 update, commit) 위주로 사용하는 거지요. 그쵸, 브랜칭, 병합 등으로 가면 헷갈리지요. 그건 개념이 달라서 어렵죠. svn은 중앙집중 관리, git은 분산 개발이 모토입니다.
      근데 git이냐 svn이냐의 선택 기준은 더 있습니다. svn은 느립니다. 특히 http에 태운 svn은 이제 2011년에 보니 문제가 심각하구나 생각이 듭니다.(아직 1.7의 http 성능 향상은 써보지 않았습니다만.)
      svn은 자체 권한 관리, http 연동, ldap 연동이 가능합니다. 그런데 git은 ssh에만 태울 수 있어서 ssh를 통해 사용자 인증을 처리해야 합니다. ldap 연동이 필요하면 ssh를 구성해야 하는 거죠.

      답글삭제
      답글
      1. 오래전 댓글이라 그런가요?
        2017년 현재는 ssh, http, git protocol, local file system 내지는 NFS 까지 지원됩니다.

        삭제
      2. 네, 오래전 댓글이라서 그렇습니다. 그당시에는 git GUI client도 없었을 때입니다. 이제는 git를 사용하는 것이 너무나 편해졌지요. 저도 새로 시작하는 수많은 프로젝트는 git를 사용합니다. 하지만 여전히 오래전부터 사용하던 SVN은 그대로 사용하고 있습니다.

        삭제
    6. 블로그를 안해서 모르는데 티스토리는 원래 댓글 줄바꿈을 없애나요? 댓글에 메일 주소 쓰는 거두 없구. 댓글 달리면 어떻게 알쥐...

      답글삭제
    7. 결론의 그외의 상황이라면 SVN을 써라보단,,개인적으론 가능하다면 Git을 써라가 낳을것같습니다.
      Git이 GUI툴의 지원이 상대적으로 부족해보이는 면이 있긴합니다.(주관적입니다)
      하지만 로컬에서의 브랜치작업은 SVN의 상대적인 직관적 사용법과 Git의 상대적인 난해함을 모두 커버하고도 남을 만큼 강력하더군요. SVN으로 브랜치생성해서 작업을 어쩌다 한번 하는 개발자는 공감하기어려울 수도 있으나 브랜치작업이 많은경우 Git은 너무나 편리합니다.

      답글삭제
    8. 안녕하세요. 나지오님

      SVN의 속도는 Git와 비교하여 가끔 이슈를 제기합니다. Git는 repository가 개인장비에 있으므로 전광석화같은 속도를 자랑하죠. ^^ 하지만 push, pull 때는 만만치 않죠. 게다가 clone을 만들 때는 많이 기다려야죠.

      SVN은 기존의 어떠한 SCM보다 빠릅니다. diff만 왔가 갔다 하므로 네트워크 상에서 속도가 빠르죠. 실제로 수백명의 개발자가 동시에 사용을 해도 성능이 문제가 되지는 않습니다.
      단 처음에 대량으로 check out을 받을 때는 좀 기다려야죠.

      SVN과 Git는 1:1로 성능 비교를 하기에는 성격이 너무 다릅니다. ^^ 둘다 좋습니다.

      답글삭제
    9. 멤피스님 안녕하세요.

      mercurial도 좋은 툴임에 틀림없습니다. Git가 사용률이 더 높으므로 대표로 말씀드립니다. mercurial이 편하면 mercurial 쓰시면 됩니다. ^^

      답글삭제
    10. 제이즈님 안녕하세요.

      SVN이냐 Git보다 어떻게 쓰느냐가 더 중요합니다.
      제가 본 90% 이상의 회사들이 SVN을 쓰던 Git를 쓰던 엉터리로 쓰면서 제 기능의 5%도 활용 못하고 있습니다.
      그만큼 제대로 쓰기는 어렵습니다.

      답글삭제
    11. 안녕하세요. trueonot님

      개발자가 아니라면 굳이 신경쓰지 않으셔도 됩니다. ^^

      답글삭제
    12. 안녕하세요. 슬픈멍멍님 ^^

      제 결론은 SVN입니다. 엄마가 좋아? 아빠가 좋아? 토론은 하루 종일 할 수도 있죠. ㅎㅎ
      SVN은 브랜치, 머지에 있어서 부족함이 없습니다. Git가 브랜치,머지가 직관적이고 쉽지만 SVN은 강력하죠. SVN의 브랜치, 머지가 좀 어렵다면 Git는 기능적으로 풍부하고 다양하지만 경험이 부족하면 어렵습니다.설명이 복잡하지만, 이게 제 결론입니다.

      답글삭제
    13. Git vs SVN은 주관적인것이기도 하지만 CVS 에서 SVN으로 거의 넘어오는 것을 보면,
      언젠가는 SVN같은 중앙 저장소 방식에서 Git,Mercurial 같은 분산 버전관리시스템으로 넘어가지 않을까 추측해봅니다 ㅎㅎ

      그러나 사실 Git 이냐 SVN 보다는 어떤 형상관리툴이라도 사용한다는게 중요한것 같습니다.

      글 잘보고 갑니다. 좋은 글 많이 부타드립니다 ^^

      답글삭제
    14. SVN을 쓰던 Git를 쓰던 거의 대부분의 회사들은 제대로 사용을 못하고 있는 것이 현실이죠.

      누가 인기를 더 끌지는 저도 궁금하네요. ^^

      답글삭제
    15. git는 소스 한번 받아 볼때 외에는 직접 사용해 본적이 없어서 잘 모르겠고
      cvs보다는 확실히 svn이 편하지만 서버구성하기가 조금 짜증이 나더라구요

      개인적으로는 svn을 사용하고 회사규모에서 사용해야 한다면 그냥 따르는것이 좋다고 봅니다 ㅋㅋ

      답글삭제
    16. 구차니님 안녕하세요.

      SVN 서버 구성은 회사에서 딱 한명만 잘 알면 되잖아요. ^^ 나머지 사람들은 감사하게 그냥 잘 쓰면 되겠죠.

      답글삭제
    17. 이번 글은 너무 명확해서 참 좋으네요.

      답글삭제
    18. 네이버에서 SVN과 GIT에 대해 검색하다가 읽게 되었습니다. 전 SVN을 잘 쓰고 있거든요. GIT가 분산저장이라는건 알겠는데 도저히 감이 안 잡히네요.

      프로젝트관리툴로는 그동안 TRAC을 써오다가 Redmine을 쓰고 있는데 GIT에 적합한 프로젝트관리툴이 뭐가 있는지도 궁금합니다.

      여튼 잘 읽고 갑니다. 아직은 SVN에 익숙해서 그런지 계속 쓰게 되네요. GIT도 차차 공부해봐야겠습니다. ㅎㅎ

      답글삭제
    19. 안녕하세요. 동범님

      Git는 서버자체를 각 PC에 두고 서로 복제하고 Merge하는 개념입니다. ^^ SVN을 잘 쓰시면 그냥 쓰시면 됩니다.

      Trac, Redmine 등은 프로젝트관리툴이라기보다는 이슈관리시스템입니다.

      대부분의 유명한 이슈관리시스템은 거의 Git, SVN 등과 연동이 잘 됩니다.

      굳이 필요하지 않은데 Git를 쓰려고 노력할 필요는 없고, 알아봐 놓는 것은 좋을 것 같습니다.

      답글삭제
    20. 좋은 글 감사합니다. 제 생각으로는 GIT은 기존 제품을 혁신하는 제품이기 보다는 오프라인에서도 사용 가능한 틈새 시장용 버전컨트롤시스템인듯합니다. GIT의 유행은 제품 자체보다 제작자(리누스 토발즈)의 네임 밸류가 큰 역할을 한거 같습니다.

      답글삭제
    21. 안녕하세요. 탐구생활님

      Git는 결코 무시할 수 없는 시스템입니다. 많은 Opensource 프로젝트가 Git를 통해서 개발하고 있고 이들 Opensource를 이용하려면 Git를 쓰는 것이 매우 유용합니다. 회사나 프로젝트의 성격에 따라서 무엇을 쓸지 정해야 하지만 Git도 중요한 고려 사항 중 하나임은 틀림없습니다.

      문제는 무슨 툴을 쓰느냐가 아니고 어떻게 사용하냐 입니다. 뭘써도 제대로 써야 하는데 제대로 쓰는 회사는 5%도 안됩니다. 잘 쓰는 것이 중요합니다.

      답글삭제
    22. 2011년/12년/13년에 걸쳐 국내 모바일 3사 중 한곳을 Plastic SCM 이라고 하는 상용 분산 VCS 시스템을 구축 및 지원 하고 있는데요. Git / Perforce / CC 의 장점이 혼재 되어 있는 도구 입니다. 15명 까지는 무료이고 국내 개발자 커뮤니티에게 무상 라이선스도 있으니 한번 자료를 보시는 것도 괜찮을 듯 합니다.
      개인적으로는 단순히 분산 리파지토리를 벗어나서 보다 진 일보된 협업 환경에서의 SCM Activity 가 늘어날 것으로 보고 있습니다. 아울러 리파지토리의 형태도 NoSQL 이나 Hadoop 혹은 Object DB 등으로 진화 해야만 Andorid 기반의 Local 빌드/릴리즈 환경을 가지고 갈 수 있습니다 대부분의 회사에서는 Git 에서 받아서 자체 SCM 창고에 가지고 갑니다.

      답글삭제
    23. 와 제가 생각하는것과 비슷하네요.
      git와 svn를 써본봐로는 기본 기능만 쓰고 소규모에서는 svn이 속편하더군요.

      답글삭제
    24. Git(정확히 말하면 GitHub)를 조금 사용해 본 결과 너무나 난해합니다. 좋은 점은 저장소가 로컬로 분산되어 있어서 개발이 빠르다는 점, Git과 Hub가 만나서 SNS 적인 통계를 제공한다는 점, 장점인지 단점인지는 모르겠으나, 모든 개발을 branch로 따고 재빠르게 작업해서 다시 merge한다는 점(이 방법은 분산 저장소 개념에 맞는 개발 방법이더군요. 공식 홈페이지에서 추천하는...)
      사실 저에게 가장 어려운 점은 저장소가 분산되고 머지되는 형태로 인해서 반드시 필요해지는 "전략"입니다. 네명이 단일 프로젝트를 관리한다고 했을 때 어떻게 branch하고 merge하는지, 분명히 정하고 넘어가야 합니다. 이게 어려워요 -_-; 사용법만 익힌다고 해결되는게 아닙니다.
      반면 SVN은 상당히 직관적이어서 commit할 때 어떻게 묶고, 이슈번호과 어떻게 연결시키느냐 정도만 정하면 무리없이 진행이 가능하고요.
      일단 git 사용은 일시중지 상태입니다. 물론 다른 프로젝트에 파생되고, 혼자 개발하는 것이라면 당연히 GitHub의 손을 들어주겠습니다. ^^

      답글삭제
    25. 전적으로 동의합니다. 이런 상황은 흔히 벌어집니다.
      특별히 분산 개발환경이 아니라면 SVN으로 거의 커버가 됩니다. Git로도 SVN과 유사하게 쓸수는 있지만 그렇게 하려면 그냥 SVN을 쓰면 되겠죠.
      물론 Git는 훌륭하지만 사용법이 복잡하고 제대로 쓰려면 많은 것이 바뀌어야 합니다. 개발하는 방식도 좀 바뀌어야 합니다.
      현재 상황에 가장 알맞는 툴을 선택해서 사용하시는 것이 좋겠습니다.

      답글삭제
    26. 다수의 사람들이 같은 코드를 건드릴 여지가 충분하고 새 피쳐 개발하면서 기존 릴리즈 관리하면서 난리부루스를 치게 되면 항상 SVN 이용할때 따라 오는 게 막판 merge시 tree conflict입니다. 간단하게 해결되는 것도 있겠습니다만... 파일명 바뀌고 위치 바뀌고 몇벙 이래저래 옮겨진 워킹브랜치를 머지하는 날에는 그야말로 지옥문이 열리는 걸 경험하실 수 있을겁니다.

      Git을 쓰는 이유? 물론 로컬 repository가 있어서 내가 새로 브랜치를 따든 커밋을 하든 준비가 되었다고 생각할때까지는 다른 작업자들에게 양향을 미치지 않고 작업할 수 있다는 장점도 있습니다만... 그 모든 것의 정점에 있는 기능은 아무래도 "Git을 사용하면 머지시 tree conflict걱정할 필요는 없다" 라는 게 아닐까요? 이거야말로 궁극적으로 팀이 Git을 사용해야 하는 이유라고 할 수 있겠지요.

      아직까지 SVN을 쓰면서 한번도 tree conflict를 본 적이 없거나 그게 뭔지도 모르겠다고 하시는 분이 계시다면... 뭔가 SVN을 잘못 쓰고 있는게 아닌지 한번쯤 고민해 보는 것도 좋을 것 같습니다.

      Git의 브랜칭 전략이라고 하면 http://nvie.com/posts/a-successful-git-branching-model/ 이걸 한번 보시는 게 좋을 것 같습니다. 아마도 이게 best practice가 아닐까 싶네요.

      답글삭제
    27. Git을 사용하면 tree conflict가 발생하지 않는다는 말씀은 이해하기가 힘드네요. 머지할 때 충돌이 나는 것이 툴로 해결될 것 같지가 않는데... 혹시 경험이 있으시다면 이 부분 설명 부탁드려요.

      그리고, 현대 개발이라는 것이 이슈트래킹과 연동을 해야하는 이슈가 있는데요 Git이 이런 운영쪽과 협업에 걸림돌이 되지는 않나요?

      베스트케이스로 보내주신 블로그는 그야말로 예술적으로 쓰는군요!!!

      답글삭제
    28. 좋은 의견 감사합니다. 메아리바람님의 질문이 있어서 몇가지 덧붙입니다.

      Git는 SVN보다 몇몇 진화된 기능이 포함되어 있습니다. SVN에서는 파일 이름을 바꾸거나 이동을 하면 추적이 안되는데 Git는 추적이 가능합니다. 따라서 Tree conflict가 줄어드는 효과가 있을 수 있습니다. 물론 SVN의 장점도 있습니다. SVN은 여러 프로젝트를 하나의 Repository에 관리하면서 공통모듈을 관리하고 부분적인 Branch를 효과적으로 사용할 수 있습니다. SVN 개발자 브랜치를 이용하면 독자적으로 개발을 해서 merge를 할 수는 있습니다.

      근본적으로 SVN을 쓰던, Git을 쓰던 Conflict를 최소화하는 개발 문화가 되어야 합니다. 구현 시작 전에 소스코드 디렉터리 구조를 미리 확정하고 파일이름도 결정해야 합니다. 또한 Public function들고 미리 정해서 컴포넌트간에 독립적으로 개발이 가능하도록 정합니다. 하나의 소스코드 파일은 나혼자만 수정한다는 생각은 버리고 동시에 수정해서 Conflict이 최소화되는 방법으로 코딩을 하는 것이 좋습니다. 여러가지 방법이 있습니다. 그리고 개발자는 프로젝트 도중에 피치못할 상황이 아니라면 파일의 Rename이나 Move는 지양해야 합니다.

      그리고 Git던 SVN이던 Merge 전략은 잘 세워서 사용해야 합니다.

      이런 환경이 아니라면 Conflict 외에도 여러가지 문제가 발생합니다. Git에서는 이런 문제를 일부 해결했습니다. Git이던 SVN이던 회사의 환경에 맞게 선택을 하는 것이 좋을 것 같습니다.

      그리고 둘다 이슈트레킹시스템과는 연동이 잘 됩니다. ^^

      답글삭제
    29. 물론 Assembly를 가지고 하던 것은 C++로 거의 다 된다.
      또한 Assembly에서 안되는 것도 C++에서 되는 것도 많다.

      그러면 C++이 Assembly보다 좋은 것인가?

      Assembly에서 제공하지 않지만 C++에서 제공하는 기능이 꼭 필요한 경우라면 C++를 사용할 수도 있다.
      - C++, C로 짜여진 수많은 라이브러리를 사용해야 할 때
      - 템플릿과 constexpr를 활용한 메타프로그래밍을 할 때
      - 다형성, 상속, 캡슐화 등을 빨리빨리 구현해야 할 때
      - RAII를 활용해야 할 때

      이런 경우가 아니라면 Assembly를 쓰는 것도 좋다. Assembly가지고 안되는 것이 있다거나 불편하다고 생각하는 사람들은 Assembly의 막강한 제어능력을 극히 일부만 활용하고 있어서 그럴 수 있다.

      답글삭제
    30. git과 svn을 asm과 C++로 연결하셨는데요, 둘이 고수준과 저수준의 차이가 나나요. 둘은 목표가 다르고 그 정도의 수준 차이도 나지 않습니다.

      논점을 제대로 집어내지 못한 오도는 쉽게 당신의 논점이 정당하다는 느낌을 주게 할 수는 있을지라도, 그 서술이 옳은 것이란 걸 증명해주진 못합니다.
      이런 게 바로 '허수아비 공격의 오류'죠. 쉬운 주장을 때리시느라 즐거우시긴 하셨겠지만 이제는 현실을 볼 때입니다.

      답글삭제
    31. 운영까지 고려하면2014년 12월 3일 오전 11:15

      동시 다발적으로 패치팀이 꾸려지고 각 팀에 대한 브렌치와 머지를 통해 프로덕트 버저닝이 필수인 운영환경에서는 git이 svn보다 이점이 많습니다.

      답글삭제
    32. Git 기반의 Open source를 이용한 개발을 해야 할 때
      Git 기반의 Open source 프로젝트에 참여할 때
      이거 아니면 깃 쓸 이유 전혀 전혀 전혀 전혀 없습니다

      솔직히 유행 따라 쓰는거지

      svn이 얼마나 좋은 툴인데 svn기능은 다 알고 그러시는건지??

      답글삭제
    33. 좋은 글입니다. 잘 읽었습니다.

      답글삭제
    34. 댓글 읽는 재미가 쏠쏠하네요. 개인적으로 git/svn의 좋은 활용 예 같은 게 있다면 찬찬히 시간 들여서 비교 분석을 하고싶네요.

      답글삭제
      답글
      1. 5년이나 된 글이고 Git도 과거보다 많이 좋아졌습니다. 지금도 회사에서는 SVN을 주로 쓰지만 OSS를 사용할 때, Prototype을 할 때는 Git를 씁니다. 만약에 회사를 처음 설립해서 최초로 선택을 한다면 아마 Git를 선택할 가능성이 더 높습니다. SVN과 Git는 SourceTree 설계 방법이 다르므로 Git 알맞게 설계를 해서 사용하겠지요.
        그럼에도 여전히 SVN의 Full 기능을 쓰고 전략을 잘 세우며 Git 부러울 것이 별로 없습니다. ^^

        삭제
    35. 오래된 글이지만 잘 보고 갑니다.

      답글삭제
    36. 오래된 글이지만 글남 겨 봅니다.

      요즘에 와서는 굳이 회사 내규에 따라서 억지로 써야 하는 경우를 제외하고는

      Git 쓰는게 훨씬 낫습니다.

      일단 svn은 중앙 서버가 맛이 가면 모든 커밋 이력이 날라 가는게 너무 크고요.

      git는 가장 최신 커밋을 가지고 있는 사람이 다시 프로젝트 만들어 push 하면 100%

      커밋이력 복구 됩니다.

      커밋내역이 많아지면.... svn보다 git가 속도가 월등히 빠르더군요....

      답글삭제