2014년 2월 19일 (수) 10:01 판

서론

연구소에서 git를 이용한 소스 코드 관리를 추진하고자 한다. git는 기능도 막강하고 무엇보다 분산 Version Control이 가능하여 개인별로 자유로운 버전 관리와 offline 모드 지원이 막강하다.

git 설치 및 설정

Linux 환경

Linux 환경에서는 기본적으로 git 프로그램이 설치되어 있다. 만약 설치되어 있지 않다면 Ubuntu 의 경우 다음 패키지를 설치한다.

$ sudo apt-get install git

git을 이용한 commit시 사용되는 기본적인 설정 정보인 사용자 이름과 이메일, commit log 메시지를 작성하는 editor를 등록한다. 설정한 정보는 사용자 홈의 .gitconfig 파일에 기록된다.

$ git config --global user.name "KyungWoon Cho"
$ git config --global user.email "cezanne@clunix.com"
$ git config --global core.editor vi

git repository 접근 하기 위해서는, 자신의 ssh public key를 등록하여 repository에 대한 접근 권한을 획득해야 한다. ssh public key를 만드는 방법은 SSH 사용법 안내 페이지를 참고

SSH config 설정

보통 ssh client 설정에서 X11 forward는 하지 않도록 다음과 같이 설정한다.

Host git 192.168.12.11
        ForwardX11 no

Windows 환경

• msysgit(Git for windows) 설치, http://code.google.com/p/msysgit/
  • 설치시 행종결자 처리에 대한 옵션을 설정하는데, 3번째 옵션인 변환을 하지 않는 것이 바람직
• TortoiseGit 설치
• Putty용 private key 파일인 ppk 파일 생성. 생성 과정은 PPKGen을 참조
• Git clone시에 생성한 ppk 파일을 지정하여 git clone

git clone

• git clone 명령은 svn checkout과 유사한 명령이다.
• 원격 git repository로 부터 로컬에 저장소를 만든다.

$ git clone git@git:testing testing

• git(192.168.12.11) 서버로 부터 testing repository를 로컬상의 testing 폴더를 작업 폴더로 만든다.
  • git은 SVN과 달리 repository에 있는 전체 저장소를 가져온다.
  • repository의 하위 폴더 일부를 가져오는 방법은 없다. 대신 submodule 기능을 통하여 하위 repository를 만들수 있다.

git add

• git은 repository에 commit을 하기전 저장공간인 staging area를 둔다.
• 신규 생성된 파일이나 기존에 존재하던 파일이라도 수정한 내용을 commit하기 위해서는 반드시 add 과정을 거쳐야 한다.

$ git add test.c

• 추가할 항목은 여러개나 glob 패턴도 가능하다.

$ git add test.c blah*.txt

• 이미 추가한 항목에 대해서는 별도로 오류를 발생하지 않고, 무시한다.

git status

• git status 는 현재 작업 폴더의 상태를 나타낸다.
• svn과 달리 상태 화면이 좀 복잡하다.

$ git status
# On branch master
nothing to commit (working directory clean)

위의 경우는 폴더에 어떠한 파일도 없거나 수정한 것이 없는 경우

$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	mytest.c
nothing added to commit but untracked files present (use "git add" to track)

mytest.c가 존재하지만, git으로 관리되지 않는 상태이다.

$ git add mytest.c
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	new file:   mytest.c
#

위의 mytest.c를 staging area에 add한 경우의 status 출력 결과이다.

기존 repository에 있는 파일을 수정한 경우라면 다음과 같은 출력 결과가 표시된다.

# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   test.c
#
no changes added to commit (use "git add" and/or "git commit -a")

위의 경우는 기존에 존재하는 파일인 test.c를 수정한 경우의 status 출력 결과이다.

이 파일을 add하면 다음과 같은 출력결과가 표시된다.

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   test.c
#

git commit

commit 과정

git commit은 staging area에 있는 변경 내용을 repository로 commit한다.

$ git commit
[master 1bf0f40] test is just test
 1 file changed, 2 insertions(+)

git commit을 수행하면 commit log를 입력하는 editor가 수행되고, editor를 저장후 종료하면 commit 과정이 완료된다. 아래는 commit 수행시 log 입력 화면예시이다.

this is test
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   test.c
#

'this is test'라는 로그메시지를 입력한 화면이며, 아래쪽 #이 표시된 영역은 단순 설명으로서 commit log에 반영되지 않는다.

• editor 편집을 취소하면 commit 과정은 자동 취소된다.
• staging area에 반영된 내용만 commit된다. staging area에 반영되지 않는 편집된 내용은 commit되지 않음을 유의해야 한다.
• commit도 일부 파일만 가능하며, 인자 없이 수행하면 staging area에 있는 전제 내용이 commit된다.

commit 전 확인 사항

협업시 공백라인이나 공백문자에 의해 변경되는 코드들은 매우 성가신 일이다. commit 전 이러한 부분이 없는지 반드시 아래 명령으로 확인을 하도록 한다.

$ git diff --check

변경사항들은 논리적인 단위로 구분해서 commit을 하도록 한다. 여러개의 이슈가 섞인 형태의 commit은 지양한다. git은 이를 위한 다양한 기능들을 제공한다.

commit 메시지는 해당 작업을 잘 표현할 수 있게끔 작성한다. 첫줄에 35글자 이하로 해당 작업 한줄로 요약한다. (영문의 경우라면 50이하) 좀 더 상세한 메시지는 한줄 공백 후 상세 내용을 작성한다.

좋은 commit 메시지의 예시

Short (50 chars or less) summary of changes
  
More detailed explanatory text, if necessary.  Wrap it to about 72
characters or so.  In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body.  The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.

Further paragraphs come after blank lines.

  - Bullet points are okay, too

  - Typically a hyphen or asterisk is used for the bullet, preceded by a
    single space, with blank lines in between, but conventions vary here

git log

git push