Extremely Agile/CVS2014.01.27 15:06

Git을 사용하다 보면 아래와 같은 상황에 자주 부딛히게 된다. 가령 어떤 branch 상에서 여러 프로그래머들이 공동으로 작업을 진행하고 있다고 하자. 


   +------------------------------> a


위의 그래프는 branch a의 초기 상태다. 이 상태에서 여러 프로그래머들이 branch를 만들면 상태는 곧 다음과 같이 바뀐다. 


                +----> a01
                |
                |
                +----> a02
                |
                |
     +--------->+ a
                |
                |
                +----> a03
                |
                |
                +----> a04


이 상태에서 몇몇 프로그래머들이 자기 브랜치를 commit하고 원래 branch에 merge 하면 branch 상태는 아래와 같이 바뀔 것이다. 


                +----> a01 +-------------+
                |                        |
                |                        |
                +----> a02 +---+         |
                |              |         |
                |              |         v
     +--------->+----^---------v--------->
                |    |
                |    |
                +----+ a03
                |
                |
                +----> a04 +---------------->


현재 a04 만이 독야청청 독자적인 길을 가고 있다. 그런데 만일 원래 branch a의 상태가 굉장히 많이 변경되어서 (가령 핵심적인 API가 바뀌었다던지) 더 이상 독자적으로 작업하는 것이 의미가 없다면? 그렇다면 원래 branch a를 다시 받은 다음, a04 브랜치에서 바꾼 파일들의 내용을 반영하도록 하는 것이 좋을 것이다. 그런 작업을 수행하는 기본적인 절차는 다음과 같다. 


1. a04 브랜치에서: git stash (현재까지 바꾼 파일들을 stash 영역에 보존한다)

2. a 브랜치로: git checkout a

3. a 브랜치에서: git pull (최신 버전으로 갱신)

4. a 브랜치에서: git branch a05 (a04의 변경 내용을 반영할 브랜치 생성)

5. a05 브랜치로 이동: git checkout a05

6. a05 브랜치에서: git stash apply --index (a04의 종전 작업 내용 반영)

7. 원래 branch a04 삭제: git branch -d a04


6 단계에서 staged 상태까지 그대로 복원하고 싶은 경우에는 끝에 --index를 붙이고, 그렇지 않은 경우에는 --index는 생략해도 된다.  


또한 4, 5, 6 단계는 git stash branch a05 명령으로 한방에 실행할 수도 있다. 주의할 것은 이렇게 하면 stash 영역에 저장된 내용은 branch에 apply된 다음에 자동으로 삭제된다는 것이다. 



저작자 표시 비영리 변경 금지
신고
Posted by 이병준
TAG Git, Stash

소중한 의견, 감사합니다. ^^

Extremely Agile/CVS2013.12.20 15:56

SVN을 사용하다 Git으로 넘어온 개발자건, 아니면 Git을 통해 소스 코드 버전 콘트롤 시스템을 처음 사용하게 된 사용자건 간에 Git을 처음 접하면 낯선 명령어와 (?) 원칙들 때문에 어려움을 겪습니다. 아마 Git을 맨 처음 접하면 가장 먼저 사용해보는 명령어는 다음과 같을 겁니다.


  • git init - 이 명령을 실행한 디렉터리를 Git 저장소로 만든다.
  • git clone /로컬/저장소/경로 - 로컬 저장소를 복제한다.
  • git clone 사용자명@호스트:/원격/저장소/경로 - 원격 저장소를 복제한다. 


이렇게 해서 복제한 (또는 생성한) 저장소는 대관절 어떻게 사용해야 하는 걸까요? git을 사용하는 방법은 너무나 다양하고 활용 범위도 너무나 넓습니다만, 초보자는 '일단' 다음의 원칙을 기억합시다. 최소한 이 절차만 알아도 팀의 일원으로써 '면피'는 할 수 있습니다. (응?) 


1. 소스 코드를 수정하고 싶다면 새로운 브랜치(branch)를 만든다.

2. 새로 만든 브랜치로 간다. (checkout) 

3. 새로운 브랜치에서 소스코드를 수정하고, add하고, commit한다. 

4. 원래 브랜치에 수정된 사항을 반영하고 싶으면, 일단 원래 브랜치로 돌아간다(checkout)

5. 그런 다음 수정이 끝난 브랜치를 병합한다(merge)

6. 원래 저장소에 반영한다. (push) (clone된 저장소의 경우만) 


이 과정을 그림으로 표현하자면 다음과 같습니다. 


http://rogerdudler.github.io/git-guide/index.ko.html


이 그림을 이해하기 위해서는 저장소를 복제하면 기본적으로 만들어지는 master 브랜치가 있다는 것. 그리고 거기에서 임의의 branch를 만들어 낼 수 있다는 것 등을 이해해야 합니다. ('새로 생성한' 저장소의 경우에는 파일을 추가하지 않으면 master 브랜치가 생기지 않으므로 주의해야 합니다. 그러니 README 파일이라도 추가한 다음에 commit해서 master 브랜치는 만들어 놓도록 합시다. Orz)


  • branch 생성: git branch <branch이름>  
  • 특정한 브랜치로 이동: git checkout <branch이름> 
  • git checkout -b <branch이름> 하면 위의 두 과정을 한 방에 수행할 수 있습니다. 
  • 새로운 브랜치에서 소스코드를 수정하는 것은 아무 편집기나 사용하셔서 하시면 되고.
  • 현재 브랜치 상태 확인: git status (변경된 파일이 있다면, 그 파일의 목록도 나타남)
  • 변경된 파일을 commit 대상에 포함시키는 명령: git add <파일경로> 
  • commit 수행 (로컬): git commit -m "<commit 로그 메시지>" 
  • 현재 브랜치에 특정 브랜치 병합: git merge <병합할 branch명> 입니다. 
  • 병합 결과를 원래 저장소로 밀어넣는 명령어는 git push origin <branch명> 입니다. 

자. 그러면 쌩초보의 git 사용 순서를 다시 한 번 정리해 봅시다. 

  • git clone <원격지 저장소명> 
  • git branch bjlee01
  • git checkout bjlee01
  • ... 소스 코드 수정 ....
  • git add modified.java
  • git commit -m "modified.java bug fix."
  • git checkout master
  • git merge bjlee01
  • git push origin master 
  • 끝. 


그러나 끝내기 전에 한 가지 원칙만 더 짚고 넘어갑시다. 기본적으로 각 branch는, 서로 다른 담당자가 있는 것 처럼 생각하세요. 그렇게 생각하면 '소스코드를 수정할 때 새로운 브랜치를 만들어야 하는 이유'가 비교적 분명해 집니다. 


그리고, 절대로 master 브랜치를 '직접' 수정하지 마세요. 인생이 고달파 집니다.
(그 이유는 다음에.) 



저작자 표시 비영리 변경 금지
신고
Posted by 이병준
TAG Git, 초보자

소중한 의견, 감사합니다. ^^

Extremely Agile/General2013.10.08 08:30

Git과 같은 분산 코드 관리 시스템의 내부 구조나 구현 방법이 궁금하신 분들이라면, 이 소식에 관심이 있으실 법 한데요. Git의 내부 구조를 설명한 Git Internal이라는 책이 오픈 소스로 풀렸습니다. (ㅎㅎ) 저자는 Scott Chacon. 


Git Internals 표지Git Internals 표지



Git의 내부 구조를 설명한 책 답게 이 책의 '소스코드'는 GitHub에 공개되어 있습니다. https://github.com/pluralsight/git-internals-pdf에 공개되어 있는데요. 라이선스는 Creative Commons Attribution-ShareAlike를 따르고 있습니다. 소스코드가 다 나와 있긴 하지만 그걸 다 받아야만 책을 읽을 수 있는 것은 아니구요. 최종 '컴파일'이 끝난 책의 PDF만 따로 받을 수도 있습니다. 



Git - Book 웹사이트Git - Book 웹사이트



한편, 인사이트에서 출간한 Pro Git의 원본도 인터넷에 이미 공개가 되어 있죠? 그 책은 http://git-scm.com/book/ko 여기서 보실수 있습니다. (물론 인사이트 책이 보기는 훨씬 더 깔끔하죠.) Git의 기본기는 이 책으로 닦고, Git의 내부구조는 재미삼아 Git Internal로 공부해 보면 좋을 것 같아요. 대가가 설계하는 소프트웨어의 내부는 어떤지 살펴본다는 것은 생각만 해도 흥미진진한일이죠. (나는 대체 언제쯤....ㅜㅜ)



저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Extremely Agile/General2013.09.22 21:05


GitHub가 오픈소스 공유 플랫폼으로 각광받으면서 덩달아 Git 또한 버전 콘트롤 시스템으로 각광받는 분위기인데요. Git은 처음에 배우기가 그다지 만만치 않습니다. SVN이나 CVS 쪽에 다양한 경험이 있어도, 배우기가 썩 편하지 않습니다.


하지만 다음 참고자료들을 '순서대로' 일별하면 쉽게 능통해 질 수 있습니다. 


1. Git 간편 안내서 - 어렵지 않아요!


http://rogerdudler.github.io/git-guide/index.ko.html





슬라이드 쇼 형식으로 필수적인 Git 명령어들을 아주 알기 쉽게 설명합니다. 여기 소개된 명령어들만 알아도 일단 Git을 시작할 수 있죠. 


2. Git Cheat Sheet


Git의 명령어들을 일목요연하게 정리해 놓은, 일종의 참조표입니다. 


http://www.insightbook.co.kr/wp-content/uploads/2013/04/git-%EC%B9%98%ED%8A%B8%EC%8B%9C%ED%8A%B8%ED%94%84%EB%A6%B0%ED%8A%B8.png





3. Git Book - 가장 자세한 Git 안내서


이렇게 해서 감 잡기가 끝나고 사용 경험이 붙었다면, 이제 좀 더 깊이 있게 공부할 순서입니다. 


http://git-scm.com/book/ko


뭐니 뭐니 해도, 이 온라인 안내서만큼 친절하고 자세한 교제는 아직 없죠. '인사이트' 출판사에서 'Pro Git'이라는 제목의 도서로도 출간되어 있습니다. 책을 구입해서 보셔도 좋겠어요. 사실 위의 참조표는 이 책의 부록이에요. 




저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 사랑을구걸하는거지

    정말 좋은 정보 감사합니다.

    2013.09.23 11:42 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 오..이런 자료를 찾고 있었는데..감사합니다!

    2015.10.12 11:21 신고 [ ADDR : EDIT/ DEL : REPLY ]