kiete1
359
2019-07-11 12:06:16 작성 2019-07-12 09:12:34 수정됨
15
2039

구글 트렌드 국가별 git vs svn


파란색이 git, 빨간색이 svn

전세계 관심도 : 2009년부터 역전하여 git 압승 (93:6)



국가별 관심도 



스웨덴, 노르웨이, 러시아, 미국, 호주, 인도, 영국 등 상위권




하위권 순위



중국 : 53% vs 47%

한국 : 62% vs 38%

일본 : 66% vs 34%




한국은 2013년부터 git이 역전하기 시작

(전 세계 평균은 2009년부터 역전)



출처 : https://trends.google.com/trends/explore?date=all&q=git,svn

1
0
  • 댓글 15

  • 능자
    2
    2019-07-11 12:09:37
    감사합니다
    0
  • 칠역한천겁
    2k
    2019-07-11 12:32:51

    git을 3년 전부터 써오고 있습니다.


    플젝개발을 혼자 해서 여러사람이랑 git을 써본적이 없어서.. git 의 장점도 모르겠는데..

    다른팀 개발자들 git 잘못써서 소스 날려먹었다느니... 쓰기 어렵다느니..

    하소연 하는걸 들으면서..


    소스관리 프로그램 때문에 스트레스를 받아야 하는지 의문이 들더군요.

    원격서버 접속 안되도 사용할수 있다가 제가 아는 제일 큰 장점인데..SVN에 비해..


    플젝하면서 원격서버에 접속이 안될 일이 얼마나 있을까 하며...

    안그래도 알아야 할 툴도 많고 언어도 많은데.. 이걸 깊이 쓰기 위해서 또 따로 스트레스 받아가며 공부를 해야 하는지 의문이네요.


    물론 여러가지 편리한 점은 알고있습니다만.. 예를들어 브랜치를 따면.. SVN은 소스 전체를 카피하지만 git은 포인터 정보 정도만 생성한다는거 등등..


    그치만... 저처럼 여러사람과 협업도 하지 않고.. 한두명 개발자가 쓰는데.. 스트레스 받아가며 git을 써야 하는지는 모르겠네요. 

    1
  • 개나소나고생
    5k
    2019-07-11 13:23:15

    이거 재미있는 통계네요.ㅎㅎ

    0
  • kiete1
    359
    2019-07-11 13:36:46 작성 2019-07-11 13:37:13 수정됨

    중국이 의외로 전세계에서 가장 svn에 관심이 많은 국가라는 게 흥미롭죠

    바로 그 뒤를 이어 동아시아 3국이 맨 뒤에 모여있는 것도 놀랍고..

    이탈리아는 독일, 영국, 미국같은 국가보다 낮을 거라는 예상은 했지만 랭크된 위치가 의외네요

    0
  • dydo_
    507
    2019-07-11 13:59:31

    git 이 쓰기 어려운 툴이라는데는 솔직히 동의할 수 없는게

    요즘 워낙 좋은 자료가 널려있어서 길어도 3일 바싹 이해하려고 하면 사용하는데 아무런 지장이 없습니다.

    소스를 날려먹는 부류는 제대로 모르는 상태로 어거지로 쓰려고 하니까 그런거구요.


    1
  • ㅇㅈㅇ
    2k
    2019-07-11 14:02:03

    개인경험으로는... 하나의 솔루션을 하더라도 소스가 이중으로 관리해야될 순간이 생깁니다.

    그러다가 머지해야하는 순간도 오죠. 그럴때는 확실히 git이 편해요. 

    반면에 모두 분담,협업해서 한줄기로 끝내고 소스가 이원화 될일도 없는 SI나 이런거 할때는

    SVN쓰는게 훨씬 편하고 잡음도 없습니다.

    0
  • 리오레오
    88
    2019-07-11 14:37:05

    익숙하면 git이 편해요.

    0
  • naucika
    62
    2019-07-11 15:41:25

    1인 개발자입니다. 저도 git 씁니다. 근데 svn 때문이 아니라, 깃랩을 설치해서 위키/CI/git/이슈관리를 한꺼번에 쓰는게 좋아서 git 을 사용하게 됬습니다;;; 물론, 1인개발이라도 메인을 건들긴 너무 작업이 클땐 브랜치도 따고 태깅도 합니다. ㅎㅎ 

    0
  • 니플
    32k
    2019-07-11 18:32:12

    git이 정확하지 않을 수도 있는 것이

    gitlab, github, 등등 깃으로 시작하는 다른 것도 같이 검색된 결과라 그렇습니다.

    gitlab, github 의 검색결과도 같이 올려주시면 좋겠습니다.



    gitlab과 git의 검색 양이 비슷하네요

    gitlab의 영향이 있을 것 같습니다.

    0
  • rezigrene
    1k
    2019-07-11 23:54:13
    // 칠역한천겁
    git의 화려한 기능을 처음부터 무리해서 써서 힘든것이고,
    브랜치 하나만으로 쓰면 svn과 큰차이 없습니다.
    git잘모르는 디자이너 분이랑 작업할땐 그런식으로 하고
    프로젝트 팀원이 받쳐주면 브랜치관리관련 새로운 시도도 해보고 그러는거죠.

    //니플
    설마 gitar 같은게 포함되었을 리가요.
    깃허브 깃랩등이 깃에 함께 포함되는것은 맞을것 같고..


    0
  • rezigrene
    1k
    2019-07-12 02:35:37 작성 2019-07-12 02:39:02 수정됨

    시작 => 개발 => 완성 => 종료 한사이클로만 이루어지는 보통의 SI에선 SVN이나 git이나 큰차이가 없습니다. 추가로 혼자서 개발하는 프로젝트에서도 별 차이는 없구요. (github의 존재 유무가 크긴하지만, 이건 두 버전 관리시스템의 차이는 아니니..)


    운영되고 있는 서비스에 계속하여 새로운 기능을 배포해야하는 경우 svn의 단점이 드러나게 됩니다.


    약간의 각색이 있긴 하지만 svn이 막장화가 되가는 과정은 다음과 같습니다.


    프로덕션버전에서 소스를 받아 개발시작.


    => 프로덕션배포전에 품질테스트 진행.


    => 품질테스트 중에도 개발자들은 열심히 개발서버에 개발버전을 올림


    => 품질테스트팀이 테스트중엔 버전 고정해 달라 항의


    => 품질테스트를 위한 서버를 만들고 특정날짜에만 한번 배포후 건드리지 않기로 함.


    => 품질테스트 중 버그가 발견되어 개발자1이 개발서버에서 버그를 수정하고, 소스관리자가 품질테스트서버에서 다시 배포버튼을 누름.


    => 각개발자들이 작업중이던 버전이 함께 품질테스트서버에 올라가면서 첫번째 혼란발생


    => 소스관리자는 고심끝에 품질테스트용 디렉토리를 별도로 만들고 개발 디렉토리를 그대로 복사해넣음


    => 개발자2는 품질테스트 디렉토리에 열심히 작업을 마침. 한편 개발자 3도 품질디렉토리에서 버그를 수정


    => 품질테스트 완료후 첫번째 프로덕션배포는 무사히 끝남


    => 소스관리자가 개발디렉토리내용을 품질테스트디렉토리로 옮김. 얼마 후 자신이 개발자2가 작업한 내용을 삭제해  버렸다는 사실을 깨달음.


    => 다행히 과거버전의 내용을 덮어씌우면서 복구하는데 성공함. 하지만 진정한 도전은 품질테스트 디렉토리에서 별도로 작업한 내용을 개발디렉토리에 합치는 것이라는 것을 깨달음.


    => 몇개 빠뜨리긴 했지만 갖은 고생을 하여 두 내용을 개발디렉토리에 합치고 품질테스트 디렉토리에 옮김. 똑같은 실수를 반복하지 않기 위해 자신이 수정한 부분을 따로 정리해 둘것을 모든 개발자에게 지시.


    => 2차 프로덕션 배포도 어찌어찌 품질테스트를 마치고 배포 성공


    => 각 개발자들은 품질테스트때 수정한 내역을 찾아 각자 개발디렉토리에 반영 작업함. 약간의 잡음이 있었으나 무사히 통합작업이 된 것처럼 보임.


    => 소스관리자는 개발자에대한 무한한 믿음을 바탕으로 개발디렉토리의 내용을 품질테스트디렉토리로 그대로 옮김. 테스트도 무사히끝나고 3차 프로덕션배포도 성공


    => 한 것 처럼보였으나 과거에  동작하던 기능 몇개가 동작하지 않음을 보고, 개발자를 믿지 못하게 됨.


    => 정책을 바꾸어 각 개발자는 개발디렉토리에서 테스트를 마치고 내용을 정리하여 품질테스트 디렉토리에 다시작업을 하는것으로 함. 그 결과 배포되었던 기능이 사라지는 현상은 사라짐.


    => 무사히 10차 프로덕션 배포까지 마친 어느날 이상한 현상이 계속 발견됨. 개발에서는 되는 기능이 품질테스트에선 동작하지 않고, 품질테스트에선 되는데 개발에선 안되는 현상이 보고됨.


    => 원인확인결과 개발디렉토리와 품질테스트 디렉토리의 내용이 너무다름. 당연히 개발디렉토리에는 개발중인 내용이 있을 것이니 다를것이나 문제는 그 이외에 더 있다는 것인데,


    퇴사한 개발자가 개발하다만 내용이 개발디렉토리에 남아있음. 개발자5는 그것을 사용해서 개발하고, 개발서버에선 문제없이 돌아가고 자신은  변경한내역 그대로 품질테스트 디렉토리에 옮겼으니 잘못없다고 버티는중.


    다수의 개발자가 품질디렉토리에서 추가 작업한 내역을 개발디렉토리에 반영하지 않은 부분을 발견함.


    반대의 경우도 발견됨. 


    그밖에 소스관리자가 급히 프로덕션 버그 수정용으로 품질테스트 디렉토리에만 작업하고 개발에 옮기는 걸 까먹은 것들.......은 조용히 묻힘.




    => 결국 새롭게 다시 시작하기로 결정.



    -------------------------------

    깃의 경우는



    소스관리자가 프로덕션 소스를 바탕으로 개발용브랜치, 프로덕션브랜치를 만듬.

    => 개발자는 개발용브랜치에 열심히 작업함.

    => 소스관리자가 개발용브랜치에서 1차품질테스트 브랜치를 생성 그리고 품질테스트 서버에 배포.

    => 품질테스트 중에 버그발견. 담당개발자는 품질테스트 브랜치에서 버그 수정 작업을 함.

    => 품질테스트가 완료되면 소스관리자는 품질테스트 브랜치를 프로덕션브랜치에 merge 후 프로덕션 브랜치를 프로덕션환경에 배포. 임무가 끝난 품질테스트 브랜치는 제거함.

    => 소스 관리자는 프로덕션 브랜치의 내용을 개발용브랜치에 merge함.

    => 소스 관리자는 개발브랜치로부터 2차품질테스트브랜치를 생성후 배포.

    => 2차품질테스트 브랜치에서 버그 수정 작업이 이루어짐.

    => 테스트 완료후 2차품질테스트 브랜치는 프로덕션브랜치에 merge되고 무사히 프로덕션환경에 배포후 앞서의 브랜치처럼 삭제됨.

    => 소스관리자는 다시 프로덕션 브랜치를 개발용브랜치에 merge함

    => 영원한 반복




    자기가 변경한 내역을 정리하라구요? 깃에 있는데?












    0
  • Frudy
    3k
    2019-07-12 05:16:19

    rezigrene

    오.....깃뉴비에게 좋은정보입니다.

    마지막답변 감사히읽겠습니다. 이해는 잘 안되네요

    나중에 다시 또 봐야겠습니다.


    0
  • 나우
    87
    2019-07-13 23:55:37

    그리 크지 않은 시스템이라도 서비스 관리와 개발을 동시에 할때 브랜치 분리해서 관리하면 정말 효율적인 것 같아요.

    깃허브 사용해서 코드 리뷰하고 문제있는 코드 라인에 직접 커멘트 해주고

    어프루브 후에 풀 리퀘스트 승인하는 것도 너무 편하고.

    백업본 계속 만들 것 없이 체크아웃으로 브랜치별로 자유자재로 수정하고 다시 머지하고.

    git 없었으면 어떻게 했을까 라는 생각이 들며 리누스 토발즈에게 정말로 감사하게 된다는..ㅎㅎ

    0
  • k20081001
    247
    2019-07-14 19:37:13
    무엇을 쓰던 상관없습니다.
    골고루 쓰는 대한민국
    0
  • 콘푸로스트
    670
    2019-07-14 23:40:43

    깃을 써보고 싶다라고 생각만하고 실제로는 써본적이 없습니다.

    혼자 튜토리얼 정도만 해봤습니다.

    커밋을해도 서버에 안올라가서 헤매였는데, 커밋이 아니라 푸시더라구요.... ㅠ


    회사 내에서 모든 프로젝트는 항상 svn만 씁니다.

    svn에는 모두 익숙하지만, git은 아직 신세계 기술이죠.

    git을 아직 써본적이 없으니, 얼마나 svn보다 좋은지는 알 수 없네요. ㅠ


    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.