Git을 조금 더 알아보자!

김 영
GIT을 조금 더 알아보자
Copyright 2018. Young Kim. All rights reserved.
young.kim@rangdebu.com

들어가기 앞서
해당 자료는 패스트캠퍼스 ‘컴퓨터 공학 실전 CAMP’ 에서
직접 강의한 내용을 바탕으로 작성되었습니다.
http://www.fastcampus.co.kr/dev_camp_cs/
현역 대학생 산업기능요원 복무가 가능한 회사로 이직 준비 중입니다. (2018.03.01 기준)
많이 연락주세요 :)
https://www.linkedin.com/in/young-kim-5438b14b/
https://www.facebook.com/ky200223

무엇을 담고있나요
VCS 중 하나인 GIT을 (CLI로)배웁니다.
GIT은 매우 기능이 많은 버전관리 도구입니다.
오픈소스에 기여를 하거나, 여러사람과
공동 작업을 하기 위해 꼭 필요합니다.
* CLI로 배우는 이유? SourceTree등의 GUI 클라이언트는 CLI만큼 세세하게 사용이 불가능합니다.
Mac / Linux을 사용하신다면 zsh라는 쉘을 사용해보시는게 어떨까요? 폴더의 GIT 상태를 나타내줘서 편합니다!
요런 모양으루다가..
Oh My ZSH! 다운로드 : http://ohmyz.sh/

VCS
더 읽어보기 : https://git-scm.com/book/ko/v2/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-%EB%B2%84%EC%A0%84-
%EA%B4%80%EB%A6%AC%EB%9E%80%3F
VCS = Version Control System
더 이상 v1.0.0.zip / v.1.0.1.zip 으로 소스코드를 관리하지 말자!

GIT
Linux 프로젝트 중 버전관리 소프트웨어의 내부 개발이 필요하다 판단되어 만들어졌습니다.
초기 개발자는 Linux의 개발자인 리누스 토발즈입니다. GIT은 다음과 같은 목표로 개발되었습니다.
더 읽어보기 : https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%ED%83%9C%EA%B7%B8
https://git-scm.com/book/ko/v2/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-Git-%EA%B8%B0%EC%B4%88
•빠른 속도
•단순한 구조
•비선형적인 개발(수천 개의 동시 다발적인 브랜치)
•완벽한 분산(DVCS)
•Linux 커널 같은 대형 프로젝트에도 유용할 것(속도나 데이터 크기 면에서)
비선형적인 개발을 위해 브랜치 시스템을 도입하였고, 원격저장소와 로컬을 분리함으로써
여러 개발자가 분산작업을 원활하게 할 수 있게 고안되었습니다.
또한, 모든 커밋에 대해 Checksum(Hash)을 만들어 데이터 무결성을 보장합니다. (SHA-1)

Inside of GIT
더 읽어보기 : http://dogfeet.github.io/articles/2012/git-delta.html
https://stackoverflow.com/questions/8198105/how-does-git-store-files
GIT은 기본적으로 파일 시스템의 스냅샷을 저장합니다.
(커밋 당시의 GIT 디렉토리의 모든 파일 정보를 저장)
또한 파일 및 스냅샷을 해시 하여 빠르게 바뀐버전인지, 아닌지 체크합니다.

Inside of GIT
더 읽어보기 : http://dogfeet.github.io/articles/2012/git-delta.html
https://stackoverflow.com/questions/8198105/how-does-git-store-files
https://medium.com/happyprogrammer-in-jeju/git-%EB%82%B4%EB%B6%80-%EA%B5%AC%EC%A1%B0%EB%A5%BC-
%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90-1-%EA%B8%B0%EB%B3%B8-
%EC%98%A4%EB%B8%8C%EC%A0%9D%ED%8A%B8-81b34f85fe53
이후 스냅샷들의 크기가 커지면 주기적으로
git gc(garbage collection)을 통해 delta를 만듭니다.

GIT vs SVN
GIT SVN
더 읽어보기 : http://tang2.tistory.com/410
https://www.slideshare.net/ienvyou/subversion-vs-git-42605130
http://pismute.github.io/whygitisbetter/
이외에도 브랜칭전략, 로컬에서만도 돌릴 수 있는가(DVCS) 등등의 차이가 있습니다.

GIT을 조금 쓸 줄 안다면..
우리가 알고 있는 깃
git init => GIT 디렉토리를 시작합시다.
git add * => GIT으로 관리할 파일을 골라봅시다.
git commit => 메시지와 함께 디렉토리의 상태를 저장합시다.
git push => 원격 저장소에 커밋 내용을 보내봅시다.
git checkout => 브랜치의 상태로 디렉토리를 변경합니다.
git branch {name} => 새로운 브랜치를 만듭니다.
git reset --hard HEAD => 마지막 커밋으로 모든 것을 되돌립니다.
git merge {branch-name} => 현재 체크아웃된 브랜치를 기준으로 name을 머지합니다.
조금 더 잘 알고 있다면…
더 읽어보기 : https://rogerdudler.github.io/git-guide/index.ko.html

File Status Lifecycle
더 읽어보기 : https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-
%EC%88%98%EC%A0%95%ED%95%98%EA%B3%A0-%EC%A0%80%EC%9E%A5%EC%86%8C%EC%97%90-
%EC%A0%80%EC%9E%A5%ED%95%98%EA%B8%B0
git status 명령어로 파일들의 상태를 확인할 수 있습니다.
git status -s 또한 유용하게 사용됩니다. (간단하게 보기)
Index,
Staging Area
라고도 부릅니다!

add
%EC%A0%80%EC%9E%A5%ED%95%98%EA%B8%B0
git add {filename} 명령어로 untracked 파일을 Staged로 만들거나,
modified 파일을 Staged로 만들 수 있습니다.
git add * 등도 많이 쓰이나, 충분히 안전할 때 사용하세요.
Index,
Staging Area

gitignore
더 읽어보기 : https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%EC%88%98%EC%A0%95%ED%95%98%EA%B3%A0-
%EC%A0%80%EC%9E%A5%EC%86%8C%EC%97%90-%EC%A0%80%EC%9E%A5%ED%95%98%EA%B8%B0
https://github.com/github/gitignore
# 확장자가 .a인 파일 무시
*.a
# 윗 라인에서 확장자가 .a인 파일은 무시하게 했지만 lib.a는 무시하지 않음
!lib.a
# 현재 디렉토리에 있는 TODO파일은 무시하고 subdir/TODO처럼 하위디렉토리에 있는 파일은 무시하지 않음
/TODO
# build/ 디렉토리에 있는 모든 파일은 무시
build/
# doc/notes.txt 파일은 무시하고 doc/server/arch.txt 파일은 무시하지 않음
doc/*.txt
# doc 디렉토리 아래의 모든 .pdf 파일을 무시
doc/**/*.pdf
GIT이 몇몇 파일을 무시하게끔 하고 싶으면? (자동생성 파일등) .gitignore를 !수동으로! 만드세요.
이는 glob 패턴을 따릅니다. (쉘 등에서 사용하는 패턴) / git clean -df 등의 명령어도 ignore안의 파일은 무시

diff
%EC%A0%80%EC%9E%A5%ED%95%98%EA%B8%B0
Staged 상태와 Unstaged (Unmodified, Modified) 상태의 차이를 보고 싶을 때 사용합니다.
git diff를 하면 Unstaged(Modifed)와 Staged를 비교해줍니다.
git diff --staged (혹은 --cached, 둘은 동일) 를 해주면 Staged와 Commited의 상태를 비교해줍니다.
git diff --name-only HEAD~1 HEAD 으로 변경된 파일만 확인할 수 있습니다. (리비전끼리)
Index,
Staging Area

commit
%EC%A0%80%EC%9E%A5%ED%95%98%EA%B8%B0
Staged 상태의 파일을 기록하기 위해서는 git commit을 할 수 있습니다.
git commit -m “커밋메시지” 를 통해 간략화하거나
git commit -a를 통해 modified(deleted 포함)를 Staged로 만든 후 커밋할 수도 있습니다.
Index,
Staging Area

rm
%EC%A0%80%EC%9E%A5%ED%95%98%EA%B8%B0
git rm {파일} 명령어를 이용하여 실제 디렉토리에서 파일을 삭제하고, Staged 할 수 있습니다.
git rm --cached 명령어를 통해 실제 디렉토리에서 삭제하지 않고 GIT 내에서만 삭제할 수도 있습니다.
그냥 rm을 하면 실제 디렉토리에서는 삭제하고, Unstaged 됩니다.
변경이 있었다면 -f 플래그(force) 를 추가해줍시다. Glob 패턴 (ignore에서 살펴본)도 사용 가능합니다.
Index,
Staging Area

log
더 읽어보기 : https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%EC%BB%A4%EB%B0%8B-
%ED%9E%88%EC%8A%A4%ED%86%A0%EB%A6%AC-%EC%A1%B0%ED%9A%8C%ED%95%98%EA%B8%B0
https://stackoverflow.com/questions/18750808/difference-between-author-and-committer-in-git
GIT에서 커밋 히스토리를 조회하기 위해 사용하는 방법입니다.
git log => 기본적인 조회
git log --oneline => 깔끔하게 보기
git log -p => 각 커밋의 diff와 함께 보기
git log --stat => 각 커밋의 통계 정보와 보기 (변경된 파일 수, insertion/deletion line 수)
git log --graph => 브랜치와 머지 히스토리까지 그래프 모양으로 보여줍니다.
git log --graph --oneline --decorate --date-order --pretty=format:'%Cred%h%Creset -%C(yellow)
%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' => 추천드리는 그래프 포맷. (alias 가능)
Author : 실제로 커밋을 한 사람
Commiter : 커밋을 GIT 레포에 저장한 사람 (pull request merge의 경우 GitHub 이라고 보입니다)

config
더 읽어보기 : https://git-scm.com/book/ko/v2/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-Git-%EC%B5%9C%EC%B4%88-
%EC%84%A4%EC%A0%95
https://git-scm.com/book/ko/v2/Git%EB%A7%9E%EC%B6%A4-Git-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0
https://drypot.github.io/writings/works/git-abc/030-configuration
https://github.com/sim0629/_/blob/master/.gitconfig
GIT을 설정해봅시다.
git config -l 을 통해 현재 config 내용을 볼 수 있습니다.
간단하게 글로벌 옵션으로 사용자명을 등록하려면, (유저 이름과 이메일 필요)
git config --global user.name “user”
git config --global user.email “user@email.com”
/etc/gitconfig # with the --system option
(mac에서는 /usr/local/etc/gitconfig, windows는 아래 첫 링크를 참조)
~/.gitconfig # with the --global option
./.git/config # default, in each git repository
이렇게 3단계로 이루어지며 아래로 갈 수록 우선순위가 높아 오버라이드 됩니다.
여기에 alias, pull 옵션, 에디터, diff, fetch 등등의 설정을 저장할 수 있습니다. (입맛대로 바꾸기)

alias
더 읽어보기 : https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-Git-Alias
GIT을 조금 더 쉽게 사용해봅시다.
git log --graph --oneline --decorate --date-order --pretty=format:'%Cred%h%Creset -%C(yellow)
%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'
이 긴 명령어를 간단하게 git graph로 만들어봅시다.
vim으로 ~./gitconfig를 열고 [alias] 아래에
graph = log --graph --oneline --decorate --date-order --pretty=format:'%Cred%h%Creset -
%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' 를 해주세요!
만들어둔 alias가 없을 경우 간단하게 alias를 만들어 본 후 이 포맷에 따라 추가해줄 수도 있습니다.
git config --global alias.ci commit => git ci가 git commit을 함.
git config --global alias.graph 'log --graph' => git graph가 git log --graph를 함.
(명령어가 플래그와 함께 있는 경우 single quote를 사용해주세요)

rewrite commit
amend
더 읽어보기 : https://git-scm.com/book/ko/v1/Git-%EB%8F%84%EA%B5%AC-%ED%9E%88%EC%8A%A4%ED%86%A0%EB%A6%AC-
%EB%8B%A8%EC%9E%A5%ED%95%98%EA%B8%B0
https://backlog.com/git-tutorial/kr/stepup/stepup7_6.html
마지막 커밋을 수정해봅시다.
git commit --amend를 통해 변경사항에 대해 마지막 커밋에 덮어씌울 수 있습니다.
SHA-1 값이 변경되기 때문에, Push한 사항에 대해 변경하는 것은 피해야합니다. (GIT은 SHA-1이 달라지면
다른 커밋으로 인식하기 때문에, 다른 작업자에게 악영향을 미칠 수 있습니다)
rebase -i
여러 커밋을 수정해봅시다.
git rebase -i HEAD~3 과 같이 대화형으로 여러개의 커밋을 순차적으로 수정할 수 있습니다.
다양한 옵션들이 있습니다.
커밋 이름 수정, 커밋 합치기, 커밋 순서 바꾸기
역시 Push된 사항에 대해서는 바꾸지 않는 것이 좋습니다.

workflow
working directory, index, HEAD
더 읽어보기 : https://git-scm.com/book/ko/v2/Git-%EB%8F%84%EA%B5%AC-Reset-%EB%AA%85%ED%99%95%ED%9E%88-
%EC%95%8C%EA%B3%A0-%EA%B0%80%EA%B8%B0
HEAD는 현재 브랜치를 가리키는 포인터이며, 브랜치는 브랜치에 담긴 커밋 중 가장 마지막 커밋을 가리킵니다.
지금의 HEAD가 가리키는 커밋은 바로 다음 커밋의 부모가 됩니다.
단순하게 생각하면 HEAD는 마지막 커밋의 스냅샷입니다.

Head search
더 읽어보기 : https://stackoverflow.com/questions/1955985/what-does-the-caret-character-mean
https://stackoverflow.com/questions/2304087/what-is-head-in-git
https://blog.npcode.com/2012/09/20/git%EC%9D%98-revision%EC%97%90-%EB%8C%80%ED%95%B4/
HEAD는 다음과 같은 방법으로 탐색할 수 있습니다.
tilde => ~{number} : HEAD로부터 몇번째 전 커밋인지
caret => ^{number} : HEAD의 parent들을 선택할 때

reset
%EC%95%8C%EA%B3%A0-%EA%B0%80%EA%B8%B0
Staging Area와 Working directory의 상태를 원래대로 되돌려봅시다.
git reset --mixed => default, HEAD를 옮기고 Staging Area를 비웁니다. (Working directory는 유지)
git reset --soft => HEAD를 옮깁니다. (Staging Area와 Working directory는 유지)
git reset --hard => HEAD를 옮기고 Staging Area를 비우고 Working directory도 해당 스냅샷으로 되돌립니다.
HEAD등을 기준으로 사용할 수도 있고,
branch이름을 주어 branch의 마지막 커밋으로 HEAD를 바꿀 수도 있습니다.
이때 branch는 변하지 않습니다.
git reset --soft HEAD를 하면 무슨 일이 일어날까요?

checkout
%EC%95%8C%EA%B3%A0-%EA%B0%80%EA%B8%B0
Reset과 비슷하다고 생각할 수 있습니다. 하지만 Branch를 옮길 때 자주 사용됩니다.
git checkout {branch} => HEAD를 branch의 HEAD로 옮깁니다. branch도 변경됩니다.

revert
더 읽어보기 : https://blog.outsider.ne.kr/1166
http://www.devpools.kr/2017/02/05/%EC%B4%88%EB%B3%B4%EC%9A%A9-git-
%EB%90%98%EB%8F%8C%EB%A6%AC%EA%B8%B0-reset-revert/
https://backlog.com/git-tutorial/kr/stepup/stepup7_2.html
commit --amend와 rebase -i, reset 등등은 커밋 자체를 수정합니다. 따라서 Push한 커밋에 대해
수정하는 것은 좋지 못합니다. (공동 작업자들이 힘들어요)
따라서 push 사항을 바꾸고 싶다면 revert를 사용합시다.
git revert {SHA}를 해주면 해당 커밋을 삭제하는 커밋을 추가할 수 있습니다.
이렇게 되면 새로운 커밋이 붙기 때문에 문제가 덜합니다.

stash
더 읽어보기 : http://wit.nts-corp.com/2014/03/25/1153
https://backlog.com/git-tutorial/kr/reference/stash.html
https://git-scm.com/book/ko/v1/Git-%EB%8F%84%EA%B5%AC-Stashing
하던 작업이 있는데 잠시 브랜치를 변경하거나, 커밋을 변경할 일이 생겼다면?
파일을 다 저장하였다가 다음에 다시 붙여넣어서 작업을 계속할 필요가 없습니다.
git stash 명령어를 사용하면 잠시 모든 상황을 담아둘 수 있습니다.
git stash는 modified된 파일과 Staging Area에 있는 파일을 스택 형식으로 저장합니다.
git stash => 현재 상황 저장
git stash save {name} => 이름으로 저장
git stash list => 스택 안의 모든 스냅샷 리스트를 확인
git stash pop => 후입 선출로 스냅샷을 뽑아낸다
git stash stash@{number} => list로 확인한 stash중 필요한 것을 뽑아낸다
git stash drop => 마지막 stash 스택의 것을 비워서 버린다. stash@{number}를 붙이는 것도 가능
git stash clear => stash 스택을 모두 비운다

branch
더 읽어보기 : https://backlog.com/git-tutorial/kr/stepup/stepup1_1.html
GIT의 꽃! 여러개의 워크플로우를 만들어낼 수 있습니다.
git branch {name} => name branch 생성
git checkout -b {name} => name branch생성하고, 이곳으로 checkout
git branch -d {name} => name branch 삭제
git branch -a => remote, local branch 모두 보기
git push --delete {remote name} {branch} => remote에서 branch 삭제
git branch --contains {SHA} => 이 커밋이 포함된 branch 찾기

branch
- 메인터넌스 브랜치(maintenance branch)
- 개발브랜치 (development branch)
- 주제 브랜치 (topic branch: feature/hotfix)
- 그 외 integration test및 experimental test용 브랜치
- 그냥 팀에 맞게 잘 하는게 중요하다! (그래도 기본 3개 있으면 좋다)
- master : 최신, 릴리즈및 버전은 여기에서 나간다, stable 브랜치라고도 합니다
- dev : 개발최신 브랜치. 개발자 개인의 테스트나 단위테스트 정도만 된 곳. 통합테스트가 안될 수도 있습니다.
보통 코드리뷰는 된 상태라고 봅니다.
- topic branch : 각자 작업자들의 작업용 브랜치. feature branch와 hotfix 브랜치로 나눠서 부르기도 합니다.
Copyright 2018. Young Kim. All rights reserved.더 읽어보기 : https://backlog.com/git-tutorial/kr/stepup/stepup1_2.html

branch
얼마든지 만들 수 있습니다…

Remote repo / Push
더 읽어보기 : https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%A6%AC%EB%AA%A8%ED%8A%B8-
%EB%B8%8C%EB%9E%9C%EC%B9%98
http://minsone.github.io/git/github-managing-remotes-changing-a-remotes-url
https://backlog.com/git-tutorial/kr/reference/remote.html
GIT은 원격 저장소를 여러개 둘 수 있습니다.
git remote add {remote name} {url} => url에 remote name을 지정하여 remote repo 저장
git remote -v => 모든 remote repo 보기
git remote set-url {remote name} {url} => remote repo의 url 변경
remote-name/branch-name 으로 remote repo와 branch 이름을 확인할 수 있습니다.
Push 명령으로 원하는 remote repo의 브랜치에 상태를 올리거나, 태그를 올리거나 할 수 있습니다.

Tracking Branch (upstream)
더 읽어보기 : https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%A6%AC%EB%AA%A8%ED%8A%B8-
%EB%B8%8C%EB%9E%9C%EC%B9%98
로컬 브랜치와 원격 브랜치를 연결해두면 push 시에 편합니다. (git push로 바로 가능)
git branch -vv => 브랜치와 이에 해당하는 Tracking branch를 확인해봅니다.
git push -u {remote name} {branch} => 현재 브랜치를 push하면서 remote의 브랜치를 트래킹하게 합니다.
git branch -u {remote name}/{branch} => 현재 브랜치가 remote의 브랜치를 트래킹하게 합니다.

fetch
더 읽어보기 : https://backlog.com/git-tutorial/kr/stepup/stepup3_2.html
원격 브랜치의 정보를 가져옵니다. 이때 FETCH_HEAD가 생성됩니다.
이를 이용해 checkout 등이 가능합니다. Merge하면 두번째 그림 모양과 같아집니다. (rebase 안할 시)

pull
pull은 fetch후 Merge까지 같이 해줍니다. (config에서 rebase하게끔 할 수 있습니다. 이를 추천합니다)
Fast-forward Merge되는 경우
Merge되는 경우

merge
더 읽어보기 : https://git-scm.com/book/ko/v1/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-
%EB%B8%8C%EB%9E%9C%EC%B9%98%EC%99%80-Merge%EC%9D%98-%EA%B8%B0%EC%B4%88
Branch를 합쳐봅시다.
요런 모양을 fast-forward merge 라고 합니다

merge
https://blog.npcode.com/2012/09/29/3-way-merge-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98%EC%97%90-
%EB%8C%80%ED%95%B4/ Copyright 2018. Young Kim. All rights reserved.
요런 모양을 3 way merge 라고 합니다
Branch를 합쳐봅시다.

Dealing with conflict situation
$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
<<<<<<< HEAD
conflict-1
=======
conflict-2
>>>>>>> conflict-2
======= 를 기준으로 현재 브랜치의 내용이 표시되고
아래에는 머지하려는 브랜치의 내용이 표시됩니다.
이를 원하는 코드로 남겨두고 <<<<<<< 와 ======= 를 지워주면
충돌 해결입니다.
다음과 같은 메시지가 뜨면서 Auto-merge가 안되는 경우가 있습니다. 한 번에 같은 부분을 수정했기 때문!
이때 git status를 하면 unmerged path에서 확인됩니다. (both modified)
unmerged path의 파일을 다시 add한 뒤 git commit 하면 Merge가 완료됩니다.

merge tool
더 읽어보기 : http://seorenn.blogspot.kr/2012/05/merge-opendifffilemerge.html
git mergetool을 이용하여 merge할 수도 있습니다.
사진은 opendiff라는 무료 머지툴입니다. 머지를 끝내고 저장하면 add까지 자동으로 해줍니다.
IDE에도 보통 들어가 있습니다. 그게 좋습니다.

rebase
더 읽어보기 : https://git-scm.com/book/ko/v1/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-Rebase%ED%95%98%EA%B8%B0
https://git-scm.com/book/ko/v2/Git-%EB%8F%84%EA%B5%AC-Git%EC%9C%BC%EB%A1%9C-%EB%B2%84%EA%B7%B8-
%EC%B0%BE%EA%B8%B0
3 way merge를 한 경우 히스토리 모양
Merge와는 다르다! 커밋 히스토리를 최대한 직선으로 만들고자 한다면?
(이진탐색 등의 편리와 커밋 히스토리의 직관성을 위하여)

rebase
rebase를 이용하면 master 브랜치 내에 결과물이 순차적으로 반영된 것 처럼 보입니다.
Merge와는 다르다! 커밋 히스토리를 최대한 직선으로 만들고자 한다면?
(이진탐색 등의 편리와 커밋 히스토리의 직관성을 위하여)

rebase
C8, C9만 master에 적용하고 싶을 수도 있습니다. (C3가 master에 없어도 될 때에)
git rebase --onto master server client 를 통해 오른쪽 모양으로 만들어 줄 수 있습니다.
(master를 merge를 통해 fast-forward 해주어야 합니다)

rebase
http://theeye.pe.kr/archives/1980
http://pinocc.tistory.com/89
rebase는 로컬에서만 하자! 이미 push 한 branch끼리 rebase하는 것은 위험합니다.
rebase는 기존 커밋을 그냥 붙이는 것이 아니라, 새로운 커밋을 만들어 붙입니다.
새로운 커밋이 생기기 때문에 Merge할 때 머리가 아파집니다..
git pull --rebase로 pull할 때 rebase를 하게 할 수 있습니다.
git config --global pull.rebase true 로 pull할 때 계속 rebase하게 하면 좋아요.
rebase도 conflict가 날 수 있음을 기억하세요!

show
더 읽어보기 : https://drypot.github.io/writings/works/git-abc/132-show
https://git-scm.com/book/ko/v1/Git-%EB%8F%84%EA%B5%AC-%EB%A6%AC%EB%B9%84%EC%A0%84-
%EC%A1%B0%ED%9A%8C%ED%95%98%EA%B8%B0
특정 파일의 특정 커밋시의 내용이나, 특정 커밋의 변경사항을 볼 수 있습니다.
git show => 마지막 커밋의 상세 내용 조회
git show {SHA} => 해당 커밋의 상세 내용 조회
git show {remote name}/{branch}:{file} => remote repo branch의 파일 조회
git show HEAD~4:{file} => 이전 커밋의 file 조회
github이나 source tree등을 사용하면 더 편하게 볼 수 있어요.

Pull Request
더 읽어보기 : https://git-scm.com/book/ko/v1/%EB%B6%84%EC%82%B0-
%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C%EC%9D%98-Git-
%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8%EC%97%90-%EA%B8%B0%EC%97%AC%ED%95%98%EA%B8%B0
GIT 자체로는 git request-pull을 이용하여 관리자에게 직접 해당 리퀘스트를 검토 후 Merge하게 합니다.
대부분의 GIT 호스팅 사이트에서는 Pull Request 버튼으로 이를 쉽게 이용할 수 있습니다.
(github, bitbucket, gogs…등등 / git request-pull 위에 UI를 만들었다고 생각하시면 됩니다.)
오픈소스 라이브러리에 기여하는 시작점입니다.
오픈소스를 먼저 clone한 후, 자신의 branch를 따고, pull request를 통해 원래 브랜치에 자신의 브랜치를
Merge해달라는 요청을 할 수 있습니다.
PR을 날리기 이전에 issue 등을 확인하여 작업 중인 사람이 있는지를 확인하거나,
자신이 이런 작업을 할 것이라고 올려주는 것이 좋습니다.
간단하게 번역 수정부터 시작해보세요. 오픈소스에 기여하는 가장 빠르고 쉬운 방법 중 하나입니다.

blame
더 읽어보기 : https://git-scm.com/book/ko/v1/Git-%EB%8F%84%EA%B5%AC-Git%EC%9C%BC%EB%A1%9C-%EB%B2%84%EA%B7%B8-
%EC%B0%BE%EA%B8%B0
http://www.whatwant.com/457
https://git-scm.com/docs/git-blame
상사에게 버그의 책임을 물을 수 있습니다(?)
각각 파일의 마지막 커미터를 보여줍니다.
git blame {파일} => 파일의 모든 행의 마지막 수정자를 보여줍니다.
git blame -e {파일} => 파일의 수정자의 이메일을 위주로 보여줍니다.
git blame -L {startline},{endline} {파일} => 특정 라인부터 특정 라인까지 보여줍니다.

tag
커밋에 릴리즈 로그를 붙이고 싶을 수 있습니다. (v1.0, v1.1, v1.2…)
Lightweight (특정 커밋에 대한 포인터), Annotated (여러 정보를 포함, Pro-git에 따르면 이를 쓰는 것이 바람직)
git tag => 전체 태그를 확인
git tag -l “v1.0*” => glob 패턴 검색과 함께 확인
git tag -a v1.0 -m "tag message" => Annotated tag를 메시지와 함께 남긴다. (HEAD 기준)
git tag -a v1.0 -m "tag message" {hash} => 특정 커밋에 대한 태그를 남긴다.
git tag -d v1.0 => 태그 삭제
git show를 통해 보면 태그 정보와 태그 이전 마지막 커밋을 보여준다.
(Lightweight인 경우는 마지막 커밋 정보만 보여준다)
*자동으로 태그를 push하지 않기 때문에, git push {리모트이름} {태그이름}으로 올려준다.
각 버전 릴리즈에 붙여 버전 식별을 쉽게 해봅시다.

reflog
GIT을 사용하던 중 커밋을 잃어버렸다면? 이때 유용하게 사용할 수 있는 명령어입니다.
예를 들어, git reset --hard HEAD^1을 하였다면 원래 HEAD였던 커밋은 어떤 브랜치에도
없는 유실된 커밋이 됩니다. 이걸 다시 찾고 싶을 때 사용해봅시다.
더 읽어보기 : https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EB%82%B4%EB%B6%80-%EC%9A%B4%EC%98%81-%EB%B0%8F-
%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%B3%B5%EA%B5%AC
https://git-scm.com/docs/git-fsck
GIT은 HEAD의 변경을 모두 기록합니다.
git log -g로 git log 형태로 볼 수 있습니다. (git log -g --oneline 으로도 볼 수 있습니다)
완전히 커밋이 유실되었다고 판단되는 경우 (.git/logs/내에서 삭제) git fsck --full 명령어를 이용하여
Dangling commit을 보고 복구할 수 있습니다.

submodule
더 읽어보기 : https://git-scm.com/book/ko/v2/Git-%EB%8F%84%EA%B5%AC-%EC%84%9C%EB%B8%8C%EB%AA%A8%EB%93%88
http://ohgyun.com/711
https://tuwlab.com/ece/26011
기본적으로, 하나의 GIT 프로젝트 안에 다른 GIT 프로젝트를 둘 수 있게 합니다.
=> 만약, 라이브러리를 가져다 쓰는 프로젝트가 있을 때, 이 라이브러리를 배포한 버전
그대로 사용하는 것이 아니라 필요에 의해 우리가 수정해서 사용하게 된다면?
우리가 수정한 라이브러리코드를 다른 저장소에 저장하고, 버전관리를 따로 해주고 싶을 수
있습니다. (원래 라이브러리에 PR등을 보내는 방법도 있지만, 그게 쉽지 않으므로…)
사용할 일이 잦진 않지만, 자주 라이브러리가 변해서 버전을 고정시키거나,
더 이상 라이브러리가 업데이트 되지 않아 직접 수정하여 쓰는 경우에 종종 사용됩니다.

GIT
더 공부해볼 것, 좋은 링크들
https://learngitbranching.js.org/
-> 브랜치 전략 및 다양한 상황을 실습해볼 수 있습니다.
https://backlog.com/git-tutorial/kr/intro/intro1_1.html
-> 한글로 GIT을 잘 설명해줍니다.
https://rogerdudler.github.io/git-guide/index.ko.html
https://opentutorials.org/course/1492
-> 정말 초심자를 위한 GIT입니다. 이정도만 해도 GIT을 사용할 수(는) 있습니다.
https://git-scm.com/book/ko/v2
-> GIT 명저 pro git의 한글 번역판입니다. 전문이 오픈되어 있습니다.

오늘은 여기까지
내용에 잘못된 부분이 있거나, 추가하시고 싶으신 내용은 언제든 환영입니다! 연락주세요!
상업적 사용, 수정, 재배포는 원작자에게 연락주신 후 진행해주세요 :)
young.kim@rangdebu.com

Git을 조금 더 알아보자!

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Git을 조금 더 알아보자!

Similar to Git을 조금 더 알아보자! (20)

Git을 조금 더 알아보자!