Git 사용 가이드

개요

Edit

• 문서의 목적
  버전관리시스템으로 Git 을 사용할 때 기본적으로 필요한 사항을 요약

• 관련 문서
  Pro Git (한글): http://dogfeet.github.com/progit/progit.ko.pdf

목표

Edit

Git 의 기본적인 기능을 사용할 수 있고 사용 중 발생하는 문제를 해결할 수 있음

git 에 대한 이해

Edit

git 의 장점

Edit

• 빠른 속도
• 단순한 구조
• 비선형적인 개발
• 완벽한 분산
• 대형 프로젝트에 유용

Local Operations

Edit

파일의 세 가지 상태

• Modified: 수정된 데이터가 아직 로컬 데이터베이스에 Commit 되지 않은 상태 - working directory
• Staged: 수정한 파일을 Commit 할 것이라고 표시한 상태 - staging area
• Comitted: 수정된 데이터가 로컬 데이터베이스에 저장된 상태 - git directory (repository)

출처: http://git-scm.com/book/ko/시작하기-Git-기초

Git 사용하기

Edit

ssh public key 등록

Edit

public key 생성

Edit

$ ssh-keygen

옵션

• -t type
  
  • 타입에는 보통 RSA 나 DSA 가 쓰입니다. (공개키 암호화 알고리즘)

$HOME/.ssh/ 에 public key 와 private 키가 생성된다.

예) 알고리즘 방식이 RSA 인 경우
-rw------- 1 skplanet staff 1679 4 2 15:25 id_rsa
-rw-r--r-- 1 skplanet staff 417 4 2 15:25 id_rsa.pub

ssh 프로토콜을 이용해 git 을 사용하기 위해서는 먼저 public key 를 저장소 서버에 등록해야 합니다.

$ cat ~/.ssh/id_rsa.pub ssh-rsa ...

Icon

조회된 결과를 [ SK Valley > 내 작업 영역 > 내 설정 > 인증 키 ]에 등록한다.

저장소 만들기

Edit

$ git init

이미 존재하는 저장소를 로컬 저장소로 가져오기

Edit

$ git clone git://server/user/path.git

이외에도 Git 은 다양한 프로토콜을 지원한다.

• git://
• http(s)://

Staged Area 에 파일 추가하기

Edit

$ git add *.java $ git add README.md

Staged Area 에 있는 파일 commit 하기

Edit

$ git commit -m "커밋 메시지"

파일 상태 확인

Edit

$ git status # On branch master # Changes to be committed: #   (use "git reset HEAD <file>..." to unstage) # #   new file:   README.md # # Changes not staged for commit: #   (use "git add <file>..." to update what will be committed) # #   modified:   benchmarks.java #

Staged Area 에 파일 빼기

Edit

$ git reset HEAD <file>

제외 항목 설정

Edit

프로젝트 루트에 .gitignore 파일을 추가한다.

.*          # dotfiles 를 제외한다. ( . 으로 시작하는 파일들 ) target/     # target 디렉토리를 제외한다.

파일 제거

Edit

$ git rm <file>

출처: http://git-scm.com/book/ko/Git의-기초-수정하고-저장소에-저장하기

저장소 서버에 push

Edit

로컬 저장소에 commit 된 내용을 원격 저장소(SK Valley)에 저장하기 위해선 push 명령을 사용해야 합니다.

먼저 등록된 원격 저장소 목록을 확인합니다.

$ git remote -v

만약, 등록된 저장소가 없을 경우 원격 저장소를 등록합니다.

$ git remote add <name> <url>

local 저장소와 remote 저장소 비교하기

git log --left-right --graph --cherry-pick --oneline branchname...remote/branchname

참고: http://stackoverflow.com/questions/5734722/git-compare-all-local-commits-to-remote-repo-version

정상적으로 등록이 되었다면 push 명령어로 로컬 저장소에 커밋된 내용을 원격 저장소에 보낼 수 있습니다.

$ git push

되돌리기

Edit

커밋 수정하기

Edit

$ git commit --amend

예를들어 커밋을 했는데 빠트린 파일이 있으면 다음과 같이 고칠 수 있다.

$ git commit -m 'initial commit' $ git add forgotten_file $ git commit --amend

여기서 실행한 명령어 세 개는 모두 하나의 커밋으로 기록된다. 두번 째 커밋은 첫 번째 커밋을 덮어쓴다.

이전 커밋으로 되돌림

Edit

$ git reset --hard HEAD^1

파일 상태를 Unstage로 변경 하기

Edit

$ git reset HEAD filename

수정된 파일 되돌리기

Edit

$ git checkout -- filename

수정 이전의 파일로 덮어씌우므로 수정했던 내용은 전부 사라지므로 위험하다. Stashing 과 Branch 를 사용하는 것을 권장.

Branching

Edit

• 브랜치에 대해 학습할 수 있는 공간
  
  • http://pcottle.github.io/learnGitBranching/
  • 한글판 : http://learnbranch.urigit.com/

Git Flow

Edit

참고 자료

Edit

• CollabNet 제공 Git pattern & anti-pattern : Git-patterns-antipatterns.pdf
• commit log
  
  • http://stackoverflow.com/questions/43598/suggestions-for-a-good-commit-message-format-guideline

• svn 사용자를 위한 간단 git 사용법
• http://blog.naver.com/h2d2002?Redirect=Log&logNo=50146029692

소스 포맷과 공백

Edit

협업할 때 겪는 소스 포맷(Formatting)과 공백 문제는 미묘하고 난해하다. 동료 사이에 사용하는 플랫폼이 다를 때는 특히 더 심하다. 다른 사람이 보내온 Patch는 공백 문자가 미묘하게 다를 확률이 높다. 편집기가 몰래 공백문자를 추가해 버릴 수도 있고 크로스-플랫폼 프로젝트에서 Windows 개발자가 줄 끝에 CR(Carriage-Return) 문자를 추가해 버렸을 수도 있다. Git에는 이 이슈를 돕는 몇 가지 설정이 있다.

core.autocrlf

Edit

Windows에서 개발하는 동료와 함께 일하면 줄 바꿈(New Line) 문자 문제가 생긴다. 윈도우는 줄 바꿈 문자로 CR(Carriage-Return)과 LF(Line Feed) 문자를 둘 다 사용하지만, Mac과 Linux는 LF 문자만 사용한다. 아무것도 아닌 것 같지만, 크로스 플랫폼 프로젝트에서는 꽤 성가신 문제다.

Git은 커밋할 때 자동으로 CRLF를 LF로 변환해주고 반대로 Checkout할 때 LF를 CRLF로 변환해 주는 기능이 있다. core.autocrlf 설정으로 이 기능을 켤 수 있다. Windows에서 이 값을 true로 설정하면 Checkout할 때 LF 문자가 CRLR 문자로 변환된다:

$ git config --global core.autocrlf true

줄 바꿈 문자로 LF를 사용하는 Linux와 Mac에서는 Checkout할 때 Git이 LF를 CRLF로 변환할 필요가 없다. 게다가 우연히 CRLF가 들어간 파일이 저장소에 들어 있어도 Git이 알아서 고쳐주면 좋을 것이다.core.autocrlf 값을 input으로 설정하면 커밋할 때만 CRLF를 LF로 변환한다:

$ git config --global core.autocrlf input

이 설정을 이용하면 Windows에서는 CRLF를 사용하고 Mac, Linux, 저장소에서는 LF를 사용할 수 있다.

Windows 플랫폼에서만 개발한다면 이 기능을 끌 수 있다. 이 옵션을 false라고 설정하면 CR 문자도 저장소에도 저장된다:

$ git config --global core.autocrlf false

core.whitespace

Edit

Git에는 공백 문자를 다루는 방법으로 네 가지가 미리 정의돼 있다.

두 가지는 기본적으로 켜져 있지만 끌 수 있고
나머지 두 가지는 꺼져 있지만 켤 수 있다.

먼저 기본적으로 켜져 있는 것을 살펴보자.

• trailing-space는 각 줄 끝에 공백이 있는지 찾는다. 
• space-before-tab은 모든 줄 처음에 tab보다 공백이 먼저 나오는지 찾는다.

기본적으로 꺼져 있는 나머지 두 개는 indent-with-non-tab과 cr-at-eol이다. 

• intent-with-non-tab은 tab이 아니라 공백 8자 이상으로 시작하는 줄이 있는지 찾는다.
• cr-at-eol은 줄 끝에 CR 문자가 있어도 괜찮다고 Git에 알리는 것이다.

core.whitespace 옵션으로 이 네 가지 방법을 켜고 끌 수 있다.
설정에서 해당 옵션을 빼버리거나 이름이-로 시작하면 기능이 꺼진다.

예를 들어, 다른 건 다 켜고 cr-at-eol 옵션만 끄려면 다음과 같이 설정한다:

$ git config --global core.whitespace \ trailing-space,space-before-tab,indent-with-non-tab

git diff 명령을 실행할 때 Git은 이 설정에 따라 검사하고 쉽게 수정해서 커밋할 수 있도록 컬러로 표시해준다. 

git apply 명령으로 Patch를 적용할 때도 이 설정을 이용할 수 있다.
Patch가 설정한 공백문자 정책에 들어맞는지 확인하려면 다음과 같이 명령어를 실행한다:

$ git apply --whitespace=warn <patch>

아니면 Git이 자동으로 고치도록 할 수 있다:

$ git apply --whitespace=fix <patch>

이 옵션은 git rebase 명령에서도 사용할 수 있다.

공백 문제가 있는 커밋을 서버로 Push하기 전에 --whitespace=fix 옵션을 주고 Rebase하면 Git은 다시 Patch를 적용하면서 공백을 설정한 대로 고친다.

출처: http://git-scm.com/book/ko/Customizing-Git-Git-설정하기#소스-포맷과-공백

한글 파일명 관련한 문제들

Edit

git status, git commit 시 한글 깨짐

git config --global core.quotepath fasle

출처: http://www.slipp.net/wiki/pages/viewpage.action?pageId=5800002

.gitignore 

Edit

IDE, OS, language에 따라 ignore할 파일들이 다른데, 아래 서비스를 쓰면 적절한 .gitignore 파일을 만들어준다. 

shell 의 function으로 사용할 수 있는 cli 도 가이드하고 있으니 참고!

http://gitignore.io/

Git Client

Edit

• SourceTree
  
  • Mac OS X 10.6+ or Windows 7: http://www.sourcetreeapp.com/

기타

Edit

• Strange behavior with git fetch: http://stackoverflow.com/questions/5094993/strange-behavior-with-git-fetch