현재 위치

홈 ›› Forums ›› 공부 ›› 프로그래밍 QnA

git나 SVN을 사용할 때 여러 대의 개발 PC를 어떻게 관리하시나요?

superkkt의 이미지
글쓴이: superkkt / 작성시간: 토, 2011/02/05 - 12:43오전

소스컨트롤을 git나 SVN을 사용하고 있습니다. 그리고 회사 PC(A), 집 PC(B), 노트북(C) 이렇게 3대의 컴퓨터에서 번갈아 가면서 개발을 하는데요.

여러분들은 여러 대의 컴퓨터 사이에서 어떻게 소스코드를 동기화(?) 하시나요? 제가 궁금한 내용은 단순히 A에서 작업하다가 커밋하고, B 또는 C에서 업데이트 받는 방법 말고, 커밋 없이 개발 도중에 다른 PC에서 작업을 이어가는 방법을 찾고 있습니다.

NFS나 Dropbox 같이 중앙 스토리지를 사용하는 방법 말고 더 좋은 방법은 없을까요?

Forums: 
프로그래밍 QnA
shint의 이미지

글쓴이: shint / 작성시간: 토, 2011/02/05 - 9:53오전

관리 능력이 부실해서
그냥 중앙서버? PC 하나에 개발환경 다 갖춘후에.
거기에 원격접속해서 개발하고 백업은 순서대로 저장만합니다. ㅠㅠ... 좀 무식하져.
근데. 전 거의 혼자 개발해서 괜찮아보입니다.
게다가. .svn 폴더가 있으면 용량이나 파일갯수가 늘어나서 좀 꺼려집니다.
git은 써보고는 싶지만. 그다지 필요성을 못느끼고 잘하지도 못해서 포기상태예요...

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

feanor의 이미지

글쓴이: feanor / 작성시간: 토, 2011/02/05 - 8:56오후

1. 가능하면 다 커밋을 합니다.
2. 1이 안되는 경우, 커밋 안 된 부분을 diff로 떠서 웹 호스팅이든 어디든 올리고, 이어서 할 때 diff를 받아서 patch를 합니다.

다른 방법도 있을텐데 제 경우에는 그렇습니다.

chadr의 이미지

글쓴이: chadr / 작성시간: 일, 2011/02/06 - 12:35오전

저도 그냥 작업한것을 로그 달아서 커밋합니다.

회사 작업물은 가능한 집에는 안들고 오고 회사에서 끝내도록 하고
개인 작업물은 가능한 회사에는 안들고 가도록 해서 한곳에 집중되도록 합니다.

ps. patch를 만드는 것도 좋은 방법 같네요. 배워갑니다.:)

-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.

이응준의 이미지

글쓴이: 이응준 / 작성시간: 일, 2011/02/06 - 3:06오전

우선 가능한 컴퓨터를 줄입니다. (현재 저는 노트북 한대만 사용합니다)

만약 그게 안된다면:
* SVN을 쓰는 상황에선 저도 feanor님처럼 패치를 메일로 보낼거고요.
* 분산형 버전관리도구를 사용하고, 동시에 <항상 켜져 있는 컴퓨터>가 있는 여건이라면, 작업중인 내용을 그곳에 push 한 후 집에서 pull 하는 것도 좋은 방법이 아닐까 싶네요. 이것도 커밋은 커밋이긴 하지만...

superkkt의 이미지

글쓴이: superkkt / 작성시간: 일, 2011/02/06 - 3:05오후

답변 감사합니다. 저는 개인적으로 완성이 안된 코드를 커밋하는걸 꺼려하기 때문에 다른 방법을 찾고 있었습니다. NFS 같은 중앙 스토리지를 쓰거나, patch로 수정 사항을 보내는 방법 외에는 딱히 좋은 방법이 없는것 같네요.

======================
BLOG : http://superkkt.com

neocoin의 이미지

글쓴이: neocoin / 작성시간: 일, 2011/02/06 - 4:48오후

말씀하신건 branch로 처리했습니다.
작은 버그 픽스로 완성되는 것을 제외하고는, 개발중인 이슈를 branch 로 빼서 작업하고, 해당 작업이 완료되면 통합 시킵니다. 미완성 코드를 commit 해도 별 걱정은 없죠.

작다고 생각한건 master에 곧바로 하는데, 이내 branch로 빼고 싶다는 생각이 드는 경우가 자주 발생하였습니다. 이는 비단 혼자 소스를 접근할때도 마찬가지 였습니다.

중앙 저장소를 쓰는 이유가 소스 동기화 때문에 쓰는 것도 한몫 하는데, 이 주옥 같은 기능을 방대한 commit log 가 생기는 것 때문에 피하는건 좀 아쉽네요.
commit log는 branch를 기준으로 읽습니다.

----

개인 경험들

1. 안쓰는 상황, 그냥 zip으로 일별 백업해서 ftp에 던져두었습니다. 애초 멀티 pc 에서 돌아다니면서 개발하는 환경이 아니라서, 위의 고민은 없었습니다. 협업도 거의 안했을때라 귀찮아도 마음의 안정을 얻었습니다.

2. cvs를 사용할때는 애초 branch가 저장소 크기 부담이 너무 크고, 소스 이동이 히스토리에 남지를 않는데다가, 당시 제가 학습이 덜된 상태라서 거의 사용하지 않았습니다. 지금 생각해도 어이 없는 수준입니다. 하지만 주기적으로 zip파일로 백업하는 것보다는 100배 좋았습니다. rollback 할수 있는데다, 하루에 한번하는 귀찮은 작업도 안해서 좋았습니다.

3. svn으로 넘어 오면서 저장소의 부담이 줄어서 branch를 쉽게 해서 좋기는 한데, 통합시 tree conflict 날때 마다 눈앞에 지옥이 열리는 기분을 맛보게 해주었습니다. 이건 한달에 한번을 겪더라도 스트레스가 심하더군요. svn이 branch는 쉬운데, merge(통합)에는 취약한 느낌입니다. 거기에 모든 commit이 네트웍을 타야되니 이것도 심하게 부담이 되었습니다. 더불어 사용 초반에 svn 이 repository가 깨지는 경험을 저에게 주었는데, 개발중이 아니었지만 지옥중에 지옥을 경험 시켜주었습니다.

4. git으로 넘어 오면서, 2,3일 고생하다가 일주일 후부터 리누스 토발즈에게 존경심이 지금까지 무럭무럭 자라고 있습니다. 특히 git을 사용하는 생각의 틀을 깨는 프로젝트들에 경우에 대하여 경이롭습니다. (최근 예 Homebrew ) 로컬에 commit하니 편하네요. master <-> branch 시에도 충돌이 나도 잘 통합되니 편합니다. 사용이 미숙해서 인지, 아직 단점은 못 느끼고 있습니다.

git에서는 특별한 경험도 손쉽게 할수 있었습니다. 동일 소스의 서버 두대를 상호 작용시켜야 할 일이었는데, 이렇게 작업할 수 있었습니다.

source main repository  (origin of local_clone1)
 |
 +--- local_clone1 (origin of local_clone2)
        |
        +----- local_clone2

이런 식으로 local_clone1에서 다시 local_clone2을 받아서 서로 소스 고쳐가며, 로컬에서 상호 동기화하면서 두 서버 테스트 할 수 있었습니다.

svn에서는 이걸 위해서 중앙 저장소를 계속 거쳐야하는데, 이건 정말 인상 깊었습니다. 요즘 결론은.. git 만세

superkkt의 이미지

글쓴이: superkkt / 작성시간: 일, 2011/02/06 - 7:42오후

감사합니다. branch로 빼서 작업하는게 좋은 방법인것 같습니다. 평소에 branch를 자주 사용하는데, 새로운 기능을 추가하다가 실패했을 때 쉽게 롤백하기 위한 용도로만 쓰다보니 미처 이런 활용 방법을 생각 못했네요.

그리고 제가 좀 변태스러운 면이 있어서인지 나중에 branch를 merge 할 때 중간 중간 임시로 커밋한 로그가 다 쌓일텐데 이게 좀 신경 쓰이긴 하네요. 이렇게 중간에 커밋할 때 로그 메시지는 보통 뭐라고 적으시나요?

======================
BLOG : http://superkkt.com

tj의 이미지

글쓴이: tj / 작성시간: 일, 2011/02/06 - 8:06오후

xxx, asdf, fdsa, foobar요.

neocoin의 이미지

글쓴이: neocoin / 작성시간: 일, 2011/02/06 - 9:27오후

자잘한 로그 관련

중간 commit 로그도 유의미하게 주려고 노력은 하는 편입니다. 하지만 고민하기 싫어서, 저는 보통 커밋 그 순간에 완료된 순간의 일을 적는 편입니다. 그러면 나중에 pull 하거나 로그 보는데도 괜찮았습니다. 그냥 몇가지 패턴 정해놓고 씁니다. 이런식으로요.

의미없지만 의미있다고 해야할까요.

coding on xx function

until xx function. 

test(ing) for xx

그외 이것 저것 느끼고 깨달은 것을 생각 정리할겸 적어봅니다.

branch를 tag 개념으로 사용해 오셨군요. 저도 초반 사용도 크게 다르지 않았습니다.

제가 이야기한 방법들이 branch 개념의 일반적인 사용 목적이고, 그냥 책에 써있는거 반복해서 말씀드리는거 같아서 쓰기가 망설였는데 참고 되셨다니 기쁘네요. 말씀하신 롤백을 용이하게 하시려면, tag를 쓰시는게 의미상으로 명확하고 편하실 겁니다. (svn에서는 두개의 구현을 다르게 표현하지 않지만 git에서는 구현도 완전히 다르게 되어 있습니다. )

svn 단점이라면, branch merge 사용 관점에서 비추 합니다. 엄밀히 말해 branch 개념 구현이 없다보니, 로그에 반영이 되지를 않습니다. 그래서 mege시에 "[MERGE_BRANCH]" 식으로 commit 로그를 이용해서 시점을 추적하는게 최선이었습니다. 그리고 branch를 만들때 이게 또 시간순으로 로그 정렬이 되거나 볼수 있는 클라이언트가 별로 없어서 branch 이름을 이런식으로 지었습니다. branches/20110102_subject 이렇게 하면 그나마 좋습니다. 그리고 일단 merge 하는 과정 외우는데 오래걸렸습니다. 이게 전 큰 문제라고 생각합니다. merge를 할때마다 쳐야하는 방대한 길이의 문자 때문에 자주 안하고 용기를 저하시킵니다. svn에서 이 반복을 없애려고 별별 환경변수를 다 세팅해놓고 썼습니다. 갈아타고 나니까 요즘, 리누스 토발즈가 코딩 신으로 보입니다. 각 문화의 좋은점만 섞어서 이렇게 규칙있게 만들다니 것 참...

git의 단점이라면, svn에 비해서 이해하고 이해 시키기가 힘듭니다. 제 자신을 어떤 도구든 불편없이 잘쓰는 편이라고 생각하는데, git의 위대함을 전파하고자하는 마음은 들지만 방법은 모르겠어요.

svn이 장점이라면, 멀티 프로젝트를 단일 저장소에 넣기에는 svn이 가장 마음에 듭니다. git은 아예 방법이 없습니다. 그리고 개념 자체가 워낙 단순하다보니, 과거에 다른 이들에게 알려주기도 편했습니다. 대학생 애들에게 저장소에 대한 교육 없이 당장 사용하게 하기에는 svn의 깔끔한 개념 만큼 좋은 도구는 아직은 없는 것 같아요. svn 0.x 대 일때는 자주 깨지고 때론 lock이 잘못 동작도 해서 백업도 늘 생각했는데, 한 몇년은 깨지는거 경험을 못했네요.

현 repository가 svn이라면 git-svn 은 이론적으로는 좋은데, 실제로 써보면 처음 commit 할때 부터 '흠... 이건 좀 아닌데'하는 느낌을 받았습니다. 늘 git을 svn에 구조에 맞춰줘야해서 매우 귀찮습니다. 그리고 tree conflict 나면 답없습니다.

현재까지 제 경험내에서는 가장 좋은건 단일 프로젝트당 git을 쓰는 거였습니다. 아직 못해본게 git submodule 입니다. github 프로젝트들 보면 상호간의 프로젝트 임베드를 잘해서 사용하는데, 이거 아주 걸작입니다. 현 프로젝트에서 써볼 기회가 없네요.

아시겠지만, git의 branch에는 /를 이용해서 일종의 namespace 처럼 branch를 구성하는걸 추천합니다. 이런식이죠.

issue/support_twitter

이러면 일부 기특한 git gui 클라이언트들은 branch 자체를 tree 형태로 조회해 줍니다. 두명 이상이 git으로 branch merge를 능숙하게 작업하고 log를 gui 클라이언트로 보면, 일이 어떻게 진행되고 있는지 정확하게 보입니다. 요즘은 이거에서 감동을 느끼죠. 상호간에 소스 리뷰하기도 매우 편하고 우수합니다. git은 기존 반복적인 일련의 작업을 줄이고 더 편하게 만들어 주었습니다. 지금까지는 정말 마음에 듭니다. svn에서는 손으로 입력한 merge 테그 시점까지 diff 떠야하는데, 이거 모아보기도 힘듭니다.

ps. 뻗어나가는 github를 보면서 구글이 많이 애탈 것 같습니다. 제가 자주쓴는 도구들도 google code에서 몽땅 github로 갈아탔고, google code는 거의 들어가지를 않네요. sf가 전부였던 세상도 있었는데, 격세지감입니다. 이 와중에 구글은 mercurial의 선택하고는 자사의 대형 프로젝트는 전부 git으로 운영하는 거보면 많이 고민될 것 같습니다. 워낙 큰 회사니 뭐..

댓글 달기

텍스트 포맷에 대한 자세한 정보

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.