1. CLI
1.1. 설치
1.2. 환경설정
1.2.1. $ git config
1.2.1.1. /etc/gitconfig 파일
1.2.1.1.1. 시스템의 모든 사용자와 모든 저장소에 적용되는 설정
1.2.1.2. ~/.gitconfig, ~/.config/git/config 파일
1.2.1.2.1. 특정 사용자에게만 적용되는 설정
1.2.1.3. .git/config
1.2.1.3.1. Git 디렉토리에 있고 특정 저장소(혹은 현재 작업 중인 프로젝트)에만 적용
1.3. Git 저장소 만들기
1.3.1. 기존 디렉토리를 Git 저장소로 만들기
1.3.1.1. $ git init
1.3.1.1.1. .git 이라는 하위 디렉토리를 만든다
1.3.1.1.2. 이 명령만으로는 아직 프로젝트의 어떤 파일도 관리하지 않는다.
1.3.2. 기존 저장소를 Clone 하기
1.3.2.1. $ git clone [url]
1.3.2.1.1. SVN의 checkout과 비슷하지만 특정 버전이 아닌 서버의 거의 모든 데이터를 복사함
1.3.2.1.2. origin이라는 리모트 저장소가 자동으로 등록됨
1.3.2.1.3. 자동으로 로컬의 master 브랜치가 리모트 저장소의 master 브랜치를 추적하도록 한다
1.4. 수정하고 저장소에 저장하기
1.4.1. 파일의 상태 확인하기
1.4.1.1. $ git status
1.4.1.2. $ git status -s $ git status --short
1.4.1.2.1. 파일 상태를 짤막하게 확인
1.4.2. 파일을 새로 추적하기
1.4.2.1. $ git add
1.4.3. Modified 상태의 파일을 Stage 하기
1.4.3.1. $ git add
1.4.4. 변경사항 커밋하기
1.4.4.1. $ git commit
1.4.4.2. $ git commit -m 'message'
1.4.4.2.1. 메시지를 인라인으로 첨부
1.4.4.3. $ git commit -a -m 'message'
1.4.4.3.1. git add 명령을 실행하는 수고를 덜어줌
1.4.5. 파일 삭제하기
1.4.5.1. $ git rm <file>
1.4.5.1.1. Tracked 상태의 파일을 삭제(정확하게는 Staging Area에서 삭제하는 것). 이 명령은 워킹 디렉토리에 있는 파일도 삭제하기 때문에 실제로 파일도 지워짐
1.4.5.2. $ git rm -f <file>
1.4.5.2.1. 이미 수정했거나 스테이징에 올린 파일을 강제 삭제 (커밋하지 않고 수정한 데이터는 Git으로 복구할 수 없음)
1.4.6. 파일 이름 변경하기
1.4.6.1. $ git mv <file_from> <file_to>
1.4.7. diff 확인하기
1.4.7.1. $ git diff
1.4.7.1.1. 워킹 디렉토리에 있는 것과 Staging Area에 있는 것을 비교
1.4.7.1.2. ★ git diff는 Unstaged 상태인 것들만 보여줌. 수정한 파일을 모두 Staging Area에 넣었다면 git diff 명령은 아무것도 출력하지 않음.
1.4.7.2. $ git diff --staged $ git diff --cached
1.4.7.2.1. 저장소에 커밋한 것과 Staging Area에 있는 것을 비교
1.4.7.3. $ git difftool
1.4.7.3.1. 외부 도구로 diff 확인하기
1.4.8. 파일 무시하기
1.4.8.1. .gitignore 파일 생성 후 무시할 파일 패턴 적기
1.4.8.2. Staging Area에 넣은 파일의 변경 부분 비교
1.5. 커밋 히스토리 조회하기
1.5.1. $ git show
1.5.1.1. 가장 최근 커밋 정보를 diff와 함께 보여줌
1.5.2. $ git show <revision || branch> $ git show <revision>..<revision>
1.5.2.1. 특정 리비전의 diff를 포함한 커밋 정보를 보여줌
1.5.3. $ git log
1.5.3.1. 가장 최근의 커밋이 가장 먼저 나온다. 그리고 이어서 각 커밋의 SHA-1 체크섬, 저자 이름, 저자 이메일, 커밋한 날짜, 커밋 메시지를 보여준다.
1.5.4. $ git log -p
1.5.4.1. 각 커밋의 diff 결과를 보여줌
1.5.5. $ git log -(n)
1.5.5.1. 최근 n 개의 커밋만 조회
1.5.6. $ git log --stat
1.5.6.1. 각 커밋의 통계 정보 조회 어떤 파일이 수정됐는지, 얼마나 많은 파일이 변경됐는지, 또 얼마나 많은 라인을 추가하거나 삭제했는지 보여준다. 요약정보는 가장 뒤쪽에 보여준다
1.5.7. $ git log --name-only
1.5.7.1. 수정된 파일의 목록만 조회
1.5.8. $ git log --graph
1.5.8.1. 브랜치와 머지 히스토리 정보까지 아스키 그래프로 보여준다
1.5.9. $ git log --pretty=oneline $ git log --pretty=short $ git log --pretty=full $ git log --pretty=fuller $ git log --pretty=format"%h - %an"
1.5.9.1. 히스토리 내용을 보여줄 때 기본 형식 이외에 여러 가지 중에 하나를 선택 가능
1.5.9.2. git log --pretty=oneline 옵션은 각 커밋을 한 라인으로 보여줘서 많은 커밋을 한 번에 조회할 때 유용하다.
1.5.9.3. format 옵션
1.5.10. $ git log --since=2.weeks $ git log --author=156506
1.5.10.1. 조회제한 조건 옵션
1.5.11. $ git log --decorate
1.5.11.1. 브랜치가 어떤 커밋을 가리키는지
1.6. 되돌리기
1.6.1. ★ 한 번 되돌리면 복구할 수 없기에 주의
1.6.2. 완료한 커밋을 수정해야 할 때
1.6.2.1. $ git commit --amend
1.6.2.1.1. 너무 일찍 커밋했거나, 어떤 파일을 빼먹었거나, 커밋 메시지를 잘못 적었을 때 기존 커밋으로 덮어쓴다.
1.6.3. 파일 상태를 Unstage로 변경하기
1.6.3.1. $ git reset <file>
1.6.3.1.1. Reset 명확히 알고 가기
1.6.3.1.2. --hard 옵션과 함께 사용하면 워킹 디렉토리의 파일까지 수정돼서 조심
1.6.4. Modified 파일 되돌리기
1.6.4.1. $ git checkout --<file>
1.6.4.1.1. 워킹 디렉토리의 수정사항을 버림
1.7. 리모트 저장소
1.7.1. 리모트 저장소 확인하기
1.7.1.1. $ git remote $ git remote -v
1.7.1.1.1. `-v`옵션을 주어 단축이름과 URL을 함께 볼 수 있다
1.7.2. 리모트 저장소 추가하기
1.7.2.1. $ git remote add <name> <url> $ git remote add origin https://...
1.7.3. 리모트 저장소를 Pull 하거나 Fetch 하기
1.7.3.1. $ git fetch <name> $ git fetch origin
1.7.3.1.1. 리모트 저장소의 데이터를 모두 로컬로 가져오지만, 자동으로 Merge 하지 않는다
1.7.3.2. $ git pull
1.7.3.2.1. Clone 한 서버에서 데이터를 가져오고 그 데이터를 자동으로 Merge 한다
1.7.4. 리모트 저장소에 Push 하기
1.7.4.1. $ git push origin master
1.7.5. 리모트 저장소 살펴보기
1.7.5.1. $ git remote show origin
1.7.6. 리모트 저장소 이름 바꾸기
1.7.6.1. $ git remote rename [변경전 단축이름] [변경후 단축이름]
1.7.7. 리모트 저장소 삭제하기
1.7.7.1. $ git remote rm [단축이름]
2. git 브랜치
2.1. 커밋 사이를 가볍게 이동할 수 있는 포인터 개념
2.1.1. 새로 브랜치를 하나 만드는 것은 41바이트 크기의 파일을(40자와 줄 바꿈 문자) 하나 만드는 것에 불과하여 비용이 거의 없음
2.2. 새 브랜치 생성하기
2.2.1. $ git branch <branch-name>
2.3. 브랜치 이동하기
2.3.1. $ git checkout <branch-name>
2.3.2. $ git checkout -b <branch-name>
2.3.2.1. 브랜치 생성과 체크아웃을 동시에
2.4. 브랜치 merge하기
2.4.1. $ git merge <branch-name>
2.5. merge 충돌 해결하기
2.5.1. $ git status
2.5.1.1. 충돌 파일 목록 확인 후 수동으로 파일 수정 및 스테이징 추가
2.5.2. $ git merge --abort
2.5.2.1. 충돌난 merge를 취소하여 이전 상태로 돌린다
2.5.2.2. Stash 하지 않았거나 커밋하지 않은 파일은 되돌리지 못한다
2.6. 브랜치 관리
2.6.1. $ git branch
2.6.1.1. 브랜치의 목록을 보여준다
2.6.2. $ git branch -v
2.6.2.1. 브랙치의 목록을 각 마지막 커밋 메시지와 함께 보여준다
2.6.3. $ git branch --merged $ git branch --no-merged
2.6.3.1. 현재 Checkout 한 브랜치를 기준으로 --merged`와 `--no-merged 옵션을 사용하여 Merge 된 브랜치인지 그렇지 않은지 필터링
2.6.4. $ git branch -d <branch-name>
2.6.4.1. 현재 checkout되지 않은 브랜치 중 merge 완료된 브랜치 삭제
2.6.5. $ git branch -D <branch-name>
2.6.5.1. merge 되지 않은 데이터를 가진 브랜치를 강제삭제할 경우
2.7. 리모트 브랜치
2.7.1. 로컬과 서버의 커밋 히스토리는 독립적임
2.7.2. 브랜치 Push 하기
2.7.2.1. $ git push <remote> <branch>
2.7.3. 브랙치 트래킹(추적)하기
2.7.3.1. $ git checkout -b <branch> <remotename>/<branch> $ git checkout -b branch1 origin/branch1
2.7.3.1.1. 로컬 브랜치와 리모트의 Upstream 브랜치 추적
2.7.3.2. $ git branch -u origin/branchname
2.7.3.2.1. 이미 로컬에 존재하는 브랜치가 리모트의 특정 브랜치를 추적하게 하기
2.7.3.3. $ git branch -vv
2.7.3.3.1. 현재 추적하고 있는 브랜치 확인
2.7.4. 브랜치 Pull 하기
2.7.4.1. $ git fetch $ git merge
2.7.4.1.1. fetch와 merge를 명시적으로 나누어서 사용한다
2.7.4.2. $ git pull
2.7.4.2.1. 서버로부터 데이터를 가져와서 현재 로컬 브랜치와 서버의 추적 브랜치를 Merge 한다
2.7.5. 리모트 브랜치 Merge 하기
2.7.5.1. $ git merge origin/master $ git merge @{u}
2.7.5.1.1. 추적 브랜치를 설정했다면 추적 브랜치 이름을 @{upstream}`이나 `@{u}`로 짧게 대체하여 사용할 수 있다
2.7.6. 리모트 브랜치 삭제하기
2.7.6.1. $ git push origin --delete <branch>
2.7.6.1.1. 협업 후 master 브랜치로 Merge 했다면, 사용했던 그 리모트 브랜치는 이제 더 이상 필요하지 않기에 삭제할 수 있다
2.7.6.1.2. 서버에서 가비지 컬렉터가 동작하지 않는 한 데이터는 사라지지 않기 때문에 종종 의도치 않게 삭제한 경우에도 커밋한 데이터를 살릴 수 있다.
3. git 도구
3.1. github
3.1.1. 계정 만들고 설정하기
3.1.2. HTML 미리보기
3.1.2.1. https://rawgit.com/[user]/[repository]/[branch]/[filename.ext]
3.1.2.2. http://htmlpreview.github.com/?
3.2. Stashing 하기
3.2.1. $ git stash
3.2.1.1. 브랜치 이동 전 아직 완료되지 않은 사항을 커밋하기 싫을 때
3.2.2. $ git stash list
3.2.2.1. 저장해둔 stash 확인하기
3.2.3. $ git stash apply
3.2.3.1. stash 다시 적용하기
3.2.4. $ git stash apply --index
3.2.4.1. Staged 상태였던 파일을 자동으로 다시 Staged 상태까지 적용
3.2.5. $ git stash branch <branch>
3.2.5.1. Stash 할 당시의 커밋을 Checkout 한 후 새로운 브랜치를 만들고 여기에 적용
3.3. 워킹 디렉토리 청소하기
3.3.1. $ git clean
3.3.1.1. 작업하고 있던 파일을 Stash 하지 않고 단순히 그 파일들을 치워버리고 싶을 때
3.3.1.2. ★워킹 디렉토리 안의 추적하고 있지 않은 모든 파일이 지워지기 때문에 신중해야 함
3.3.2. $ git clean -f
3.3.2.1. 강제의 의미. '진짜로 그냥 해라'
3.3.3. $ git clean -d
3.3.3.1. 하위 디렉토리까지 모두 지워버린다
3.3.4. $ git clean -n
3.3.4.1. 가상으로 실행해보고 어떤 파일들이 지워질지 알려달라
3.4. Git 로그 검색
3.4.1. $ git log -S<string> --oneline
3.4.1.1. 어떤 문자열이 가장 처음 나타난 때를 찾는 문제라면 -S 옵션을 이용해 해당 문자열이 추가된 커밋과 없어진 커밋만 검색할 수 있다
3.4.2. $ git log -L :<function>:<file>
3.4.2.1. 라인 히스토리 검색.
3.4.2.2. 함수의 시작과 끝을 인식해서 함수에서 일어난 모든 히스토리를 함수가 처음 만들어진 때부터 Patch를 나열하여 보여준다
3.4.3. $ git blame -L <lines> <file> $ git blame -L 38,40 layout.html
3.4.3.1. 한 줄 한 줄 마지막으로 커밋한 사람이 누구인지, 언제 마지막으로 커밋했는지 볼 수 있다
3.5. Bundle
3.5.1. $ git bundle create repo.bundle HEAD master
3.5.1.1. 파일을 이메일로 보내거나 USB로 다른 사람에게 보내고 싶을 때
3.5.1.2. master 브랜치를 다시 만드는 데 필요한 모든 정보가 다 들어 있다
3.5.2. $ git clone repo.bundle
3.5.2.1. 필요한 곳에 bundle 파일을 놓고 풀어서 사용한다
3.6. Reset 고급
3.6.1. Git은 서로 다른 세 트리를 관리하는 컨텐츠 관리자
3.6.1.1. HEAD
3.6.1.1.1. 마지막 커밋 스냅샷, 다음 커밋의 부모 커밋
3.6.1.2. Index
3.6.1.2.1. 다음에 커밋할 스냅샷
3.6.1.3. 워킹 디렉토리
3.6.1.3.1. 샌드박스
3.6.2. $ git reset --soft HEAD~
3.6.2.1. 1 단계: HEAD 이동
3.6.2.1.1. Index나 워킹 디렉토리는 그대로 놔두고 브랜치가 가리키는 커밋만 이전으로 되돌린다
3.6.3. $ git reset --mixed HEAD~
3.6.3.1. 2 단계: Index 업데이트
3.6.3.1.1. 이전 커밋으로 돌리고 Staging Area를 비우기까지 한다
3.6.4. $ git reset --hard HEAD~
3.6.4.1. 3 단계: 워킹 디렉토리 업데이트
3.6.4.1.1. 이전 커밋으로 돌리고 워킹 디렉토리의 내용까지도 되돌린다
3.6.4.1.2. merge를 되돌리고 싶을 때도 사용한다
3.6.5. $ git reset <file> (=$ git reset --mixed HEAD file.txt)
3.6.5.1. 1단계:HEAD 이동을 건너뛰고 Index를 HEAD가 가리키는 상태로 만든다.
3.6.5.1.1. 해당 파일을 Unstaged 상태로 만든다
3.7. git svn
3.7.1. 양방향 Subversion 지원 도구
3.7.2. 기업에서 git을 사용할 수 있도록 돕는 출발점
4. Git gui 환경에서 사용하기
4.1. $ gitk
4.1.1. (git 설치 시 자동설치) 히스토리를 그래프로 보여준다
4.2. $ git gui
4.2.1. (git 설치 시 자동설치) 커밋 도구
4.3. GitHub 클라이언트
4.4. 다른 gui 도구들
4.4.1. 다운로드
4.4.2. gui 클라이언트 Feature Matrix
4.4.3. 14 Best Git clients for Windows as of 2017
5. VCS(Version Control System)
5.1. 중앙집중식 버전 관리(CVCS)
5.1.1. Subversion(SVN), CVS, Perforce...
5.1.2. 장점
5.1.2.1. 관리수월
5.1.3. 단점
5.1.3.1. 중앙 서버가 다운되면 협업 불가능
5.1.3.2. 중앙 데이터베이스가 있는 하드디스크에 문제가 생기면 모든 히스토리를 잃음
5.2. 분산 버전 관리(DVCS)
5.2.1. Git, Mecurial, Bazaar, Darcs...
5.2.2. 장점
5.2.2.1. 빠른 속도
5.2.2.2. 단순한 구조
5.2.2.3. 비선형적인 개발(수천 개의 동시 다발적인 브랜치)
5.2.2.4. 완벽한 분산
5.2.2.5. Linux 커널 같은 대형 프로젝트에도 유용함(속도나 데이터 크기 면에서)
5.2.3. 단점
5.2.3.1. SVN에 익숙한 사용자에게 헷갈림
5.3. Git vs SVN
5.3.1. Diff가 아니라 스냅샷
5.3.1.1. SVN: 각 파일에 대한 변화를 시간순으로 관리하면서 파일 집합을 데이터로 관리
5.3.1.2. Git: 데이터를 스냅샷의 스트림처럼 취급하고 크기가 작다.
5.3.2. 거의 모든 명령을 로컬에서 실행
5.3.2.1. 모든 히스토리가 로컬 디스크에 있기 때문에 모든 명령이 순식간에 실행
5.3.2.2. 오프라인 상태나 VPN 비연결 상태에서도 커밋 가능
5.3.3. 데이터를 추가할 뿐 되돌리거나 삭제할 방법이 없음
5.3.3.1. 프로젝트가 망가질 걱정없이 다양한 실험 가능
5.3.4. 세 가지 상태
5.3.4.1. 세 가지 단계
5.3.4.1.1. 워킹 디렉토리
5.3.4.1.2. Staging Area
5.3.4.1.3. Git 디렉토리
5.3.4.2. Modified
5.3.4.2.1. 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않은 것
5.3.4.3. Staged
5.3.4.3.1. 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태
5.3.4.4. Committed
5.3.4.4.1. 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미