Embed Size (px)
DESCRIPTION
What is git & How to use git. By Nakhyun Choi ( bbashong ). 가여운 프로그래머가 한명있다 . 이창원 (21 세 , 남 ) 그에게는 두가지 고민이 있다 . 첫 번째 고민. 내가 개발하고 있는 프로그램 A 가 잘못 되었을 때 과거의 어떤 시점으로 다시 되돌아가고 싶어 !. 그의 해결법. 프로젝트에 변경 사항이 있을 때 마다 프로젝트 폴더 전체를 복사해서 다른이름으로 저장해두자 ! - PowerPoint PPT Presentation
Citation preview
What is git &How to use gitBy Nakhyun Choi (bbashong)
가여운 프로그래머가 한명있다 . 이창원 (21 세 , 남 )
그에게는 두가지 고민이 있다 .
첫 번째 고민 내가 개발하고 있는 프로그램 A 가 잘못 되었을 때 과거의 어떤 시점으로 다시 되돌아가고 싶어 !
그의 해결법 프로젝트에 변경 사항이 있을 때 마다 프로젝트 폴더 전체를 복사해서 다른이름으로 저장해두자 ! 조금 많이 귀찮겠지만 개발하다 삐끗해서 전체 프로젝트를 날리는 것 보단 났겠지 ..
두 번째 고민 다른 프로그래머인 박보영 (43 세 , 남 ) 씨와 같은 프로젝트를 함께 진행하고 싶어 !
그의 해결법 프로젝트에 변경사항이 있을 때 마다 전체 프로젝트 폴더를 서로에게 Email 로 보내서 싱크를 맞추자 !
어떻게 됬을까 ? 처음 서너번은 잘 프로젝트를 복사해 두었지만 너무 귀찮아서 안하게 되었다 . 몇달 뒤 , 개발중 치명적인 버그가 생겨서 다시 예전으로 돌아가려 했지만 코드가 너무 꼬여 처음부터 다시 짜게 되었다 . 프로젝트에 신입 팀원이 10 명 추가되었다 . 이제 그는 프로그램을 한번 수정할 때 마다 11 명의 팀원에게 메일을 보내야 한다다 . 이제 그는 11 명의 팀원이 보낸 메일을 받아야 한다 .
좀 더 멋진 해결법이 없을까 ? VCS(Version Control System) 을 사용한다 .
VCS(Version control System)? 각 파일 , 전체 프로젝트를 이전 상태로 되돌릴 수 있다 . 시간에 따라 수정 내용을 비교해 볼 수 있다 . 누가 문제를 일으켰는지 추적해 볼 수 있다 . CVCS 나 DVCS 를 사용하면 쉽게 다른 프로그래머와 협업할 수 있다 .
CVCS vs DVCS CVCS(Centralized VCS) : 중앙 집중식 버전 관리 시스템 DVCS(Distributed VCS) : 분산형 버전 관리 시스템
CVCS 의 특징 모든 파일을 관리하는 서버가 따로있고 많은 클라이언트가 이 중앙 서버에서 파일을 받아서 사용한다 (Checkout).
관리하기가 쉽다 Subversion 이 대표적인 예이다 .
But, 만약 중앙서버가 한시간 동안 다운되면 아무도 다른사람과 협업할 수 없고 했던 일을 백업할 수도 없다 .
만약 중앙서버의 하드디스크에 문제가 생기면 프로젝트를 복구할 수 없다 .
DVCS 의 특징 전체 저장소를 클라이언트가 가지고 있다 . 중앙서버가 다운되거나 인터넷을 사용 할 수 없어도 충분히 작업을 진행할 수 있다 . 중앙서버의 하드디스크에 문제가생겨도 클라이언트의 저장소로 복구할 수 있다 . 대표적으로 동아리에서 자주 사용되는 mercurial(hg) 와
git 이 있다 .
git? DVCS 이다 .
리눅스의 창시자인 리누스 토발즈가 원래 사용하고 있던 BitKeeper 라는 VCS 를 사용할 수 없게 되면서 직접 VCS 를 개발하였다 .
git? Git 은 다음과같은 4 가지 목표를 가지고 개발되었다 .
빠른 속도 단순한 구조 비 선형적인 개발 ( 동시 다발적인 수천개의
branch) 완벽한 분산
Git을 배우려면 Subversion이나 Perforce 같은 다른 VCS를 사용하던 경험을 지워버려야 한다 . ( 물론 다른 vcs 를 사용한 경험이 있는 사람만 )
차이점이 아닌 snapshot
일반적인 vcs
git
거의 모든 명령을 로컬에서 실행한다 . 다른 vcs 에 비해 미친듯이 빠른 속도를 가진다 .
오프라인 상태에서도 commit 하고 비교할 수 있다 .
Git 은 무조건 데이터를 추가하기만한다 git 으로 무얼하던 데이터는 추가되기만 한다 . 손실되는 데이터는 절대 없다 . 프로젝트가 망가질 걱정 없이 재미있는 실험들을 해볼 수 있다 .( 물론 git 을 잘 쓸 줄 알면 )
세가지 상태
Git 기본설정설치는 그냥 apt-get 하면 됩니다 . 따라해보세요 emacs 쓸줄 모르잖아요 ..
Git 의 3 가지 설정 파일 /etc/gitconfig 파일 : 시스템의 모든 사용자와 모든 저장소에 적용되는 설정이다 . git config --system 옵션으로 이 파일을 읽고 쓸 수 있다 . ~/.gitconfig 파일 : 특정 사용자에게만 적용되는 설정이다 . git config --global 옵션 으로 이 파일을 읽고 쓸 수 있다 . .git/config: 이 파일은 Git Directory 에 있고 특정 저장소 ( 혹은 현재 작업 중인 프로 젝트 ) 에만 적용된다 . 각 설정은 역순으로 우선시 된다 . 그래서
.git/config 가 /etc/ gitconfig 보다 우선한다 .
편집기 $ git config --global core.editor vi
Diff 도구 $ git config --global merge.tool vimdiff
설정 확인 $ git config --list
Tip git source code 의 contrib/completion 의
git-completion.bash 를 홈디렉에 숨김파일로 복사하고 .bashrc file 에 source ~/.git-completion.bash 을 추가하면 자동완성을 사용할 수 있다 .
Git-completion.bash 를 찾기 귀찮으면 arari서버의 bbashong홈디렉에 있으니 복사해가면됨 .
git 의 기초지금부터 하는 모든 내용은 remote 서버와 관련 없이 , 인터넷 연결 없이 , local 에서 할 수 있는 내용 들 입니다 . remote 서버에 연결해서 협업하는 부분은 더 뒤에 설명할 것 입니다 .
하지만 이번 실습에선 ! 서버에서 받지 말고 각자 개인의 repository 를 만들어서 실습을 해봅시다 .
working directory 를 만들고 그 directory 안에서 $git init
기억하세요 아까 말씀드린 git 에서 file 의 3 가지 상태를 기억하세요 .
실습 다같이 arari.sparcs.org 로 ssh 접속을 해보고 저를 따라해보세요
기본 명령어 git status git add git commit & git commit -a Staged 의 개념 파일 무시하기 (.gitignore file)
diff 사용법 git diff : staged 된 data 와 working
directory 의 data 를 비교한다 git diff --cached or git diff --staged : 저장소에 commit 된 data 와 staged 된
data 를 비교한다 .
파일 삭제와 이름 변경 git rm git mv
commit log 확인 git log 옵션 설명
-p 각 커밋에 적용된 패치를 보여준다 .--stat 각 커밋에서 수정된 파일의 통계정보를 보여준다 .--shortstat `--stat` 명령의 결과 중에서 수정한 파일 , 추가된 줄 , 삭제된 줄만 보여준다 .--name-only 커밋 정보중에서 수정된 파일의 목록만 보여준다 .--name-s tatus 수정된 파일의 목록을 보여줄 뿐만 아니라 파일을 추가한 것인지 , 수정한 것인지 , 삭제한 것 인지도 보여준다 .--abbrev-commit 40자 짜리 SHA-1 체크섬을 전부 보여주는 것이 아니라 처음 몇 자만 보여준다 . --relative-date 정확한 시간을 보여주는 것이 아니라 `2 주전`처럼 상대적인 형식으로 보여준다 . --graph 브랜치와 머지 히스토리 정보까지 아스키 그래프로 보여준다 .--pretty 지정한 형식으로 보여준다 . 이 옵션에는 oneline, short, full, fuller, format이 있다 . format 은 원하는 형식으로 출력하고자 할 때 사용한다 .
log format argument Option Description of Output %H Commit hash
%h Abbreviated commit hash %T Tree hash %t Abbreviated tree hash
%P Parent hashes%p Abbreviated parent hashes%an Author name%ae Author e-mail%ad Author date (format respects the –date= option) %ar Author date, relative%cn Committer name%ce Committer email%cd Committer date%cr Committer date, relative%s Subject
조회 제한 -(n) 최근 n 개의 커밋만 조회한다 .
--since, --after 명시한 날짜 이후의 커밋만 검색한다 . --until, --before 명시한 날짜 이전의 커밋만 조회한다 . --author 입력한 저자의 커밋만 보여준다 .--committer 입력한 커미터의 커밋만 보여준다 .
git log hash.value
커밋 수정하기 $git commit --amend $git reset HEAD <file>.. $git checkout <file>
branchgit 의 핵심 git 의 앙꼬
branch란 ? commit 사이를 자유롭게 움직이며 특정
commit 을 가리키는 포인터 같은 것이다 .
initial condition
$git branch testing
$git checkout testing
some commit
$git checkout master
commit again
merge 의 개념 1. 작업 중인 웹사이트가 있다 .
2. 새로운 이슈를 처리할 새 Branch 를 하나 생성 .3. 새로 만든 Branch 에서 작업 중 .
그런데 작업도중에 hotfix 를 당장 만들어야 하는 일이 생겼다 . 1. 새로운 이슈를 처리하기 이전의 운영 (Production) 브랜치로 복원 .
2. Hotfix 브랜치를 새로 하나 생성 .3. 수정한 Hotfix 테스트를 마치고 운영 브랜치로 Merge.4. 다시 작업하던 브랜치로 옮겨가서 하던 일 진행 .
merge 하기 전의 상태
$git checkout master$git merge hotfix Updating f42c576..3a0874c
Fast forward README | 1 -1 files changed, 0 insertions(+), 1 deletions(-)
cont’d
$git checkout iss53some commit
basic merge
$git checkout master$git merge iss53
When conflicted 같은파일의 같은부분을 여러 branch 에서 동시에 수정하다보면 conflict 가 날 때가 있다 .
이럴경우에는 $git status 명령으로 conflict 를 일으킨 파일을 확인할 수 있다 .
해당파일을 직접 열어 수정하거나 $git mergetool 을 이용하여 수정할 수 있다 . conflict 를 해결한 뒤에 다시 commit 해준다 .
branch 관리 $git branch : 현재 존재하는 branch 표시
--merged : merge 된 것만 보여줌 --no-merged : merge 와 반대
branch 를 삭제하려면 반드시 merge 가 되어있어야 한다 .삭제는 $git branch -d branch_name
Branch workflow그럼 이 branch 를 왜 만든 거고 어떻게 써먹어야 할까 ?
Long running branch 배포했거나 배포 할 code 들만 master
branch 가 가리킨다 .
개발하고있는 code 는 develop 이라는 branch 를 만들어 개발한다 .
develop branch 가 안정되면 master branch 와 merge 한다 .
Long running branch
Topic branch branch 예제에서 했던 것 처럼 하나의 issue당 하나의 branch 를 만드는 것이다 .
이렇게 branch 를 막 만들어도 되는가 ? 이것이 바로 git 의 장점이다 . git 에서의
brancgh 는 단순히 41바이트짜리 포인터 일 뿐이다 .
초고속으로 branch 를 만들고 쉽게 merge 할 수 있다 .
수천 수백개의 branch 를 만들어도 전혀 문제가 없다 .
Rebase merge 와 비슷하면서도 다른 개념 branch history 를 깔끔하게 만들고 싶을 때 쓴다 .
잘못 사용한다면 위험하다 .
사실 “이미 공개 저장소에 Push 한 커밋을 Rebase 하지 마라” 라는 규칙만 잘 지키면 위험할 건 없다 .
시간상 생략하겠다 . 궁금하면 찾아오세요
협업하기드디어 가장 중요한 part 에 도착했다 .remote repository 에 연결하여 다른사람과 협업하는 과정을 알아보자 .
git server 설정
protocol http/s, git, ssh, local 4 가지의 protocol 이 있다 .
자세한 protocol별 장단점은 시간상 생략한다 .
우리는 가장 무난한 ssh protocol 을 사용 할 것이다 .
bare repository 만들기 bare repository란 working directory 가 없는 git repository 를 뜻한다 . 정말 저장소만 있다 . repository 를 다른사람과 공유하려면 bare하게 만들어야한다 . $git clone --bare -- shared arari arari.git 협업하는 사람들이 반드시 arari.git 폴더에 대해 읽기권한과 쓰기권한을 가지고 있어야 한다 .
gitweb 생략
기본 명령어 $git remote : 현재 import 된 remote 저장소를 보여준다 . 처음 clone 한
repository 는 origin 으로 저장된다 . $git push [remote name] [branch
name]: remote repository 로 내 저장소를 push 한다 .
$git fetch [remote name] : repository에서 data 를 가져온다 $git pull : fetch 와 비슷하나 merge 를 한다 .
Remote branch 이해remote repository 에도 branch 는있다 .
$git clone [email protected]:project.git
remote 와 local 에서 각각 2 번의 커밋이 생김 .
$git fetch origin
push 하기 serverfix 라는 branch 를 다른사람과 공유하기위해 push 한다고 해보자 $git push origin serverfix 를 실행한다 . 이제 remote repository 에는 내가 commit한 serverfix 라는 branch 가 존재한다 .
다시 fetch 하기 $git fetch origin
위 명령을 실행시키면 내 repository 에 serverfix 와 같은자리에 origin/serverfix 라는 branch 가 생긴다 .
헷갈려선 안되는 점은 serverfix 라는 branch 가 새로생기거나 update 되는 게 아니고 수정할수없는 origin/serverfix 라는 branch 가 생기는거다 .
serverfix 와 origin/serverfix 는 별개의 branch 이다 .
Branch Tracking serverfix 와 origin/serverfix 는 완전 별개의
branch 라고 하였다 . 그렇다면 둘사이에 연결고리를 만드는 방법은 뭘까 ?
git checkout -b [branch] [remote]/[branch]
첫 번째 branch name 을 적지 않으면 remote의 두 번째 인자의 branch name 과 같아진다 .
Branch Tracking $git checkout -b serverfix
origin/serverfix
이제 serverfix 에 checkout 된 상태에서 $git push 를 하면 remote 와 branch 이름을 적어주지 않아도 알아서 origin repository 의 serverfix branch 에 커밋이 된다 .
$git pull 을 해도 자동으로 origin/serverfix와 serverfix 를 merge 한다 .
remote branch 삭제 remote repository 의 branch 가 필요없어지면 다음과 같은 특이한 명령어로 삭제할 수 있다 .
$git push [remotename] :[branch] (‘]’ 과 ‘ :’ 사이에 공백 주의 )
사실 위 명령어는 $git push [remotename] [localbranch]:[remotebranch]에서 응용된 것인데 현재 checkout 된 branch 가 아닌 localbranch 를 remotebranch 에 푸쉬하겠다는 말 이다 .
그런데 local branch 부분이 비어있기때문에 빈 branch 로 대체되어 branch 가 삭제된다 .
수고하셨습니다 .referencepro-git : http://git-scm.com/book번역판 : http://bit.sparcs.org/~bbashong/progit.ko.pdf
