[입 개발] git 이것만 배워도 github에 pull request 날릴 수 있다#1

Git 이라는 것은  DVCS(Distributed Version Control System)의 한 종류로, DVCS 대한 개발이나 개념 같은 것들은 http://en.wikipedia.org/wiki/Distributed_version_control_system 에 잘 나와있으니 따로 설명하지 않겠습니다.

물론 잘못 배워두면 나중에 후회하지만, 여기서는 쉽게 이해를 하기 위해서, 극단적으로 제 마음대로 설명을 하겠습니다. 먼저 VCS는 뭘까요? 코드를 개발하다보면, 백업이 필요합니다. 당장 내가 코드 변경한 것이 잘못 날려서 울어야 하는 케이스도 있고, 내가 이걸 왜 했던가에 대한 고민도 하게 되고, 때로는 기능별로 다르게 적용해야 되서, 백업을 남겨둬야 할 경우도 있습니다. 이럴때 보통 사람들의 행동 패턴은 다음과 같습니다.

  1. 다 날리고 다음번에 후회하며 우는 사람(charsyam)
  2. 날짜별 기능별로 폴더를 만들어서 압축해서 정리하는 사람
  3. VCS 류를 이용해서 깔끔하게 원하는 형태로 관리하는 사람

자꾸 VCS가 뭔지 설명도 안하고, 들먹거리느랴고 얘기하지만, 앞에서 말한 예를 도와주는 툴이라고 생각하면됩니다. 예를 들어서 checkout->modify->commit 이라는 절차를 거치면 그 간의 작업 내용이 history로 남습니다. 그리고 그 시점으로 쉽게 돌아가거나, 변화를 추적할 수 있습니다.

그런 것들이 CVS가 있었고, SVN 으로 나갔다가 git/mecurial 같은 DVCS 까지 시대가 바뀌고 있지만, 사실 뭘 써도, 이런걸 쓰고 있다면, 크게 반대할 이유도 없고, 그냥 이런거 모른던 사람이면 git을 쓰면 좋겠다라는 것입니다.

일단 svn 이나 git을 모르더라도 두 개의 가장 큰 차이를 들자면(아무도 동의안하겠지만…) 변경이 저장되는 중간 계층이 있다는 것입니다. DVCS의 모두가 중요한 레포지토리라는 말은 솔직히 좀 허황된 느낌도 있고(최종본은 어디론가 모여야 한다는…) 그리고 그렇게 접근하면 좀 어려운 느낌도 강하게 듭니다.

보통 SVN은 소스를 수정하고 바로 commit을 하면 remote에 있는 소스저장소에 바로 저장이됩니다. 이렇게 되면, 내 코드가 작성중에 커밋을 해두기 어렵게 됩니다.(사실, 이건 branch를 쓰면 다 잘 해결이 되지만!!!), 그 과정동안 위에서 발했던 데이터 손실등이 얼마든지 발생할 수 있습니다. 그런데 git을 쓰면 로컬에 commit을 하고 이 history를 가지고 있다가 원하는 시점에 remote 의 소스 저장소에 보낼 수 있습니다. 기록을 모두 남겨둘 수도 있고, 변경 사항을 다 모아서, 나는 버그따위는 없는 완벽한 개발자야라는 느낌으로 보낼수도 있습니다.(ㅋㅋ)

그럼 일단 git을 사용할려면 어떻게 하는 것이 좋을지에 대해서 말을 하자면 다음 과정으로 간단하게 작업이 끝납니다.

  1. github.com 이나 bitbucket.org 에 가입한다.
  2. 해당 사이트에서 새로운 repository 를 생성한다.
  3. git clone git주소(해당 repository에 보면 clone을 위한 주소가 있음)
  4. 소스 수정
  5. git add 변경 파일들
  6. git commit -m “변경 사항 abc”
  7. git push

여기서 git commit 이 로컬 저장소에 저장하는 것이고(네트웍이 연결될 필요가 없습니다.)

git push 가 원격 저장소에 집어넣는 것입니다.  그런데 오픈소스에 컨트리뷰션 하기 위해서는 pull request를 날리는 과정이 생기는데, github을 예로 간단하게 설명하자면 먼저 원 프로젝트 사이트에서 fork를 누릅니다. 예를들어 제 guoid 프로젝트를 예로 든다면…

  1. redis repository 포크
  2. git clone 으로 해당 프로젝트를 받아옴
  3. git remote add 이름 원래git주소(여기서는 git remote add guoid https://github.com/charsyam/python-guoid.git)
  4. git checkout -b 브랜치이름(git checkout -b issue-110)
  5. 코드 수정
  6. git add 수정 파일들
  7. git commit -m “수정내용 #abc”
  8. git push 브랜치이름(git push origin issue-110)
  9. 이러면 github 사이트에 branch 에 해당 이름으로 브랜치가 생기므로 여기서 pull request 명령을 눌러주고 내용을 적으면 끝입니다.
  10. git checkout master(or unstable, 메인 브랜치명)

그 뒤로 원래의 사이트에 수정내용이 생기면 다음과 같이 하면 됩니다.

  1. git fetch guoid
  2. git merge guoid/master( or unstable 메인 브랜치명을 적어줌)
  3. git push origin 하면 최종 내용으로 반영이 됩니다.(전 이걸 몰라서 예전에 매번 브랜치를 지웠다는 ㅋㅋㅋ)

다음 편에서는 sourcetree 라는 멋진 툴을 이용하는 방법과 git flow라는 git 방법론에 대해서 알아보도록 하겠습니다.