4. 버전 관리 시스템의 형태
로컬 오직 로컬에서만 버전 관리
중앙집중식 예) 디렉토리를 이용한 파일시스템이
나 데이터베이스를 활용한 로컬 VCS
분산형
협업이 불가
5. 버전 관리 시스템의 형태
로컬 저장소인 중앙 서버가 있고 클라이언
트가 파일을 체크아웃
중앙집중식
예) CVS, Subversion, Perforce, …
분산형
중앙 서버에 문제가 발생한 동안 협
업이 불가
6. 버전 관리 시스템의 형태
로컬 각 클라이언트가 모두 저장소를 가짐
중앙집중식 예) Git, Mecurial, Bazaar, Darcs …
분산형 서버에 문제 생겨도 지속적인 작업
가능
서버의 저장소가 날아가도 복원 가능
커밋 속도 빠름
오프라인에서도 작업 가능
중앙집중식 외에 다양한 워크플로우
구현 가능
• 계층 모델 등
7. GIT?
역사
2002년부터 리눅스 커널에 사용된 BitKeeper가 2005년 이익다툼으로
리눅스 커뮤니티와 관계가 틀어짐
그 이후, 리누스 토발즈가 직접 git을 만들었고, 지금까지 계속 발전해 옴
강점
빠른 속도로 대형 프로젝트에 사용하기 좋음
편리한 브랜치 사용
8. GIT?
델타가 아닌 스냅샷으로 저장
이전 버전에서 바뀐 델타 값을 저장하는 기존 시스템과는 다르게 매 커
밋 순간의 스냅샷을 저장
9. GIT?
SHA-1을 이용한 무결성
파일을 이름이 아닌 SHA-1 체크섬(해시값) 단위로 저장, 관리
• 해싱에는 파일의 내용이나 Directory 구조가 이용됨
• 체크섬은 40자 길이의 16진수 문자열
오직 git을 통해서만 원하는 파일에 접근, 수정
10. GIT?
파일의 세 가지 상태
Modified
• 수정만 하고 Stage나 커밋하지 않
은 상태
• 작업 디렉토리에 존재
Staged
• 현재 수정한 파일을 곧 커밋할 것
이라고 표시한 상태
• staging area에 존재
Committed
• 파일이 로컬에 안전하게 저장된
상태
• git 디렉토리에 존재
13. GIT 설치 과정
소스코드로 설치
• 라이브러리(curl, zlib, openssl, expat, libiconv) 설치
$ yum install curl-devel expat-devel gettext-devel
openssl-devel zlib-devel
$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext
libz-dev libssl-dev
• 소스코드 다운: http://git-scm.com/download
• 컴파일
$ tar -zxf git-1.7.2.2.tar.gz
$ cd git-1.7.2.2
$ make prefix=/usr/local all
$ sudo make prefix=/usr/local install
14. GIT 설치 과정
패키지 관리도구로 설치
$ yum install git-core
$ apt-get install git-core
기본 설정
$ git config --global user.name [user-name] # 유저 이름 설정
$ git config --global user.email [user-email] # 유저 이메일 설정
$ git config --global core.editor [editor-name] # 사용할 편집기 종류 선택
15. GIT 기초 명령
저장소 만들기
• 새 저장소 만들기
• .git 디렉토리가 생성됨
$ git init
• 이미 있는 저장소를 복제
• 해당 url에 있는 저장소를 통째로 복제
• 프로토콜은 file, git, ssh, http(s) 가능
$ git clone [url]
$ git clone [url] [new-project-name]
16. GIT 기초 명령
수정하고 저장소에 저장
• 수정된 파일 stage하기
• tracked 상태인 파일 중, 수정된 파일을 staged 상태로 만듦
• 새 파일(untracked)인 경우, tracked로 되면서 동시에 stage됨
• 디렉토리인 경우 하위 파일 모두 재귀적으로 적용
$ git add [file-name]
• 파일의 상태 확인
$ git status
17. GIT 기초 명령
수정하고 저장소에 저장
• 변경 내용 비교하기
• unstaged와 staged 간 비교
$ git diff
• staged와 commited 간 비교
$ git diff --staged
18. GIT 기초 명령
수정하고 저장소에 저장
• 변경 사항 커밋하기
$ git commit
• 코멘트를 쉘에 직접 적어서 커밋
$ git commit –m [comment]
• 변경된 파일을 stage없이 바로 커밋
$ git commit –a –m [comment]
19. GIT 기초 명령
수정하고 저장소에 저장
• 파일 삭제하기
• 주의! 그냥 작업 디렉토리에서 rm 명령쓰면 git에 반영안됨
$ git rm [file-name]
• 파일 이름 변경
• 그냥 작업 디렉토리에서 mv 명령쓰면 역시 git에 반영안됨
$ git mv [file-from] [file-to]
20. GIT 기초 명령
커밋 히스토리 조회
$ git log
• 주요 옵션
-p 각 커밋에 적용된 패치를 보여준다.
--stat 각 커밋에서 수정된 파일의 통계정보를 보여준다.
--graph 브랜치와 머지 히스토리 정보까지 아스키 그래프로 보여준다.
--pretty 지정한 형식으로 보여준다. 이 옵션에는 oneline, short, full, fuller, format이
있다. format은 원하는 형식으로 출력하고자 할 때 사용한다.
-(n) 최근 n 개의 커밋만 조회한다.
--since, --after 명시한 날짜 이후의 커밋만 검색한다.
--until, --before 명시한 날짜 이전의 커밋만 조회한다.
--author 입력한 저자의 커밋만 보여준다.
--grep 커밋메시지에 원하는 단어가 포함된 커밋만 보여준다.
21. GIT 기초 명령
되돌리기
• 커밋 수정하기
$ git commit --amend
• staged인 파일을 다시 unstaged로 변경하기
$ git reset HEAD [file-name]
• 수정된 파일 되돌리기
• 한번 되돌리면 복구 불능! branch를 쓰는 것이 더 나은 방법임
$ git checkout -- [file-name]
22. GIT 기초 명령
리모트 저장소
• 리모트 저장소 확인
• 저장소를 복제한 경우 origin이라는 리모트 저장소 자동 등록됨
$ git remote
• url까지 확인
$ git remote -v
• 더 상세히 살펴보기
$ git remote show [remote-name]
23. GIT 기초 명령
리모트 저장소
• 리모트 저장소로부터 fetch/pull
• fetch는 로컬에는 없고 리모트에는 있는 데이터를 모두 가져옴
$ git fetch [remote-name]
• pull은 fetch도 하고 자동으로 로컬 브랜치와 머지까지 시켜줌
$ git pull [remote-name]
• 리모트 저장소에 push
• 먼저 fetch/pull을 통해 최신상태로 만든 다음에야 push 가능
$ git push [remote-name] [branch-name]
32. 브랜치
충돌
• 머지하는 두 브랜치에서 같은 파일의 한 부분을 동시에 수정했을 경
우 충돌이 일어남
• git status 명령으로 어느 파일에서 충돌나는지 확인 가능
• 충돌난 파일의 표시된 부분을 찾아 직접 수정해야 함
• git mergetool
• 수정 후 git commit 하면 머지 완료됨
33. 브랜치
리모트 브랜치
• 리모트 저장소에 있는 브랜치
• 로컬에서는 [remote-name]/[branch-name] 형식으로 표시
• git clone 했을시 로컬에 origin/master 브랜치 자동 생성됨
36. 브랜치
리모트 브랜치
• 로컬에서 리모트로 push하기
$ git push [remote-name] [branch-name] # 같은 이름으로 push
$ git push [remote-name] [branch-name-local]:[branch-name-remote]
# 다른 이름으로 push
• 리모트 브랜치 삭제
$ git push [remote-name] :[branch-name]
37. 브랜치
Rebase
• 머지와 기능은 같으나 커밋 히
rebase merge
스토리가 선형으로 깔끔하게 기
록됨
Cherry-pick
• 현재 브랜치에 특정 과거 시점
의 커밋의 패치만 반영하면서
머지
38. 목차
개념과 특징
설치와 기초 명령
브랜치
어플리케이션
• Git flow
• Gerrit
• Gitlab & Gitlab CI
39. GIT FLOW
통상적으로 개발에 쓰이는 몇
개의 브랜치만 정의하고 편리하
게 사용할 수 있게 해줌
master 브랜치
develop 브랜치
feature 브랜치
release 브랜치
hotfix 브랜치
40. GIT FLOW
master 브랜치
• 최종 릴리즈된 소스코드만 관리
develop 브랜치
• 개발 중인 코드를 관리
feature 브랜치
• develop 브랜치로부터 특정 새로운 기능을
구현 할 때 파생
• 완료후 다시 develop 브랜치로 머지
release 브랜치
• develop 브랜치에서 master 브랜치로 머지
하기전 최종점검을 위한 브랜치
hotfix 브랜치
• 현재 릴리즈 되어 있는 코드의 버그를 긴
급 수정할 때 사용
41. GIT FLOW
설치하기
$ sudo apt-get install git-flow
사용하기
• 초기화(작업 디렉토리에서)
$ git flow init
• 새 브랜치 파생 및 기존 브랜치로 머지
• <base>는 기존 브랜치의 특정 시점(commit ID)
$ git flow <branch> start <name> [<base>]
$ git flow <branch> finish <name>
42. GERRIT
git 위에서 돌아가는 웹 기반 코드 리뷰 도구
Google에서 사용한다고 알려져 있음
특징
• 이전 버전과 코드 비교, 라인 단위의 코멘트, 코드 승인 프로세스를
지원
43. GITLAB
git을 바탕으로 웹 상에서 코드리뷰, 이슈 관리, 위키 등을 제공하는 통합
서비스
gerrit과의 비교
• 코드리뷰(단, 코드 승인 프로세스는 없음) 외 추가 기능
• 디자인이 더 좋음