git add 를 실행한 이후, git diff 를 통해 차이를 확인할 수 없음
왜냐면 staged 상태(add 한 이후)이기 때문에.
staged 상태인 파일 변화를 확인하려면 --cached 혹은 --staged 옵션을 추가

git diff --cached
git diff --staged

 

-v 옵션을 통해, commit message 에 diff 메세지도 추가 가능

git commit -v

 

-a 옵션을 통해, git 이 tracking하는 모든 파일을 stage area 에 넣고 commit 할 수 있음
즉, git add 를 생략하고 바로 commit 가능함

git commit -a

 

local machine 에서 파일을 지웠다고 해서, git 의 repo에서도 파일이 지워진 것은 아님
git rm 를 통해 git 에도 '해당 파일을 지웠다'는 걸 알려줘야 함

 

git rm 명령어는 local machine 의 파일까지 같이 삭제함
local 에서는 삭제하지 않고, git 에서만 삭제 및 tracking을 하지 않도록 하려면 --cached 옵션 사용

git rm --cached README.md

 

최근 로그의 diff 결과를 최근 2개 보여주는 명령어

git log -p -2

 

로그에서 각 커밋의 통계 정보 확인하는 명령어

git log --stat

 

로그에서 브랜치 상태 그래프를 같이 보여주는 명령어

git log --graph

 

지난 2주 동안 만들어진 커밋을 보여주는 명령어

git log --since=2.weeks

 

코드에서 추가 및 제거된 내용(업데이트 된 내용)을 검색할 수 있는 옵션은 -S
예를 들어, 문제를 일으키는 "issued_function_name" 라는 함수가 어느 커밋에서 발생했는지 검색하려면

git log -p -S issued_function_name

 

특정 경로 내 파일들의 로그(커밋 정보)를 보여주는 옵션은 --
예를 들어, /a/b/c, ./d/e 두 위치 안에 있는 파일들의 커밋 로그를 보려면

git log -- /a/b/c ./d/e

 

git commit 실행했을 때, (commit 에 포함되어야 할)어떤 파일 추가하는 것을 깜빡했다면
add 한 이후 --amend 명령어를 사용하여 commit 에 포함시킬 수 있음
예를 들어

git commit -m "commit without a file"  # 넣어야 할 파일을 빠뜨린 채로 commit
git add forgotten_file  # 잊은 파일을 추가
git commit --amend  # commit 에 합침

참고로 첫번째로 진행한 커밋(git commit -m "commit without a file") 기록은 사라지게 됨

 

remote 저장소 리스트를 보려면
git remote -v

결과 :
origin https://github.com/schacon/ticgit (fetch)
origin https://github.com/schacon/ticgit (push)

여기서 origin 은, git clone시 사용된 git주소의 별명(단축 이름)임
remote 저장소 이름을 보려면

git remote
remote 저장소를 추가하려면

git remote add pb_repo https://github.com/paulboone/ticgit

git remote -v 실행 결과 :
origin https://github.com/schacon/ticgit (fetch)
origin https://github.com/schacon/ticgit (push)
pb_repo https://github.com/paulboone/ticgit (fetch)
pb_repo https://github.com/paulboone/ticgit (push)

 

로컬에는 없지만 리모트 저장소의 모든 데이터를 가져오려면

git fetch origin  # origin 저장소에서 가져옴
git fetch pb_repo  # pb_repo 저장소에서 가져옴
git fetch  # 로컬에 등록된 모든 저장소에서 가져옴

fetch 를 통해 가져온 데이터는 로컬 브랜치에 자동으로 Merge 하지 않음
로컬 브랜치에 병합(merge)하려면, 수동으로 처리해야 함
로컬에는 없지만 리모트 저장소의 모든 데이터를 가져와서 로컬 브랜치에 merge 까지 하려면

git pull

 

리모트 저장소의 자세한 정보를 보려면

git remote show origin 

 

'HEAD' 는 작업중인 브랜치를 가리키는 포인터
git checkout 등으로 작업 브랜치를 바꾸면, HEAD 포인터가 옮겨진 브랜치를 가리키도록 바뀜

 

 

https://git-scm.com/book/ko/v2/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

위와 같이, master 브랜치를 기준으로 두 개의 브랜치(hotfix, iss53)가 추가되었고
master 브랜치와 hotfix 브랜치를 병합해야 하는 경우

git checkout master
git merge hotfix

결과 : 
Updating f42c576..3a0874c
Fast-forward
 index.html | 2 ++
 1 file changed, 2 insertions(+)

여기서 fast-forward 병합이 이루어짐
hotfix 는 master 브랜치를 기반으로 업데이트 된 브랜치기 때문에,
단순히 master 브랜치를 가리키는 포인터가 hotfix 브랜치를 가리키도록 이동한 것 (결과 아래) 

https://git-scm.com/book/ko/v2/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

 

 

 

 

https://git-scm.com/book/ko/v2/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

 

위와 같이, iss53에 따로 커밋이 이루어지고 이를 master 브랜치에 병합하는 경우

git checkout master
git merge iss53

결과 : 
Merge made by the 'recursive' strategy.
index.html |    1 +
1 file changed, 1 insertion(+)

iss53 은 (현재) master 브랜치에서 뻗어나온 브랜치가 아니기 때문에, fast forward merge 를 할 수 없음
대신, 각 브랜치(master, iss53)가 가리키는 커밋 두 개와 공통 조상 하나를 사용하여 3-way merge 를 함
master 브랜치 커밋(C4)과 iss53 브랜치 커밋(C5)을 합친 하나의 새로운 커밋(C6)을 생성한 후,
master 브랜치가 C6 커밋을 가리키도록 만듦으로써 3-way merge 를 마무리함

https://git-scm.com/book/ko/v2/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
https://git-scm.com/book/ko/v2/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

 

 

 

 

만약 위의 케이스에서 hotfix 와 iss53 에서 동일한 파일을 서로 다르게 업데이트 한 경우,
충돌로 인해 3-way merge 진행시 merge 가 진행되지 못함
merge 충돌 발생시 어떤 파일을 merge 할 수 없었는지 확인하려면

git status


git 에서 <<<<, >>>> 등으로 충돌 난 부분을 표시해줌
그리고 개발자는 이 파일의 충돌 난 부분을 수동으로 수정함
파일 수정이 마무리되면, git add 명령을 시작으로 다시 커밋을 진행

 

브랜치 목록에서 이미 merge 가 된 브랜치를 보려면

git branch --merged

이 명령으로 나타나는 브랜치들은 이미 merge 가 마무리 된 것이기 떄문에 삭제해도 무방
브랜치 목록에서 merge 가 되지 않은 브랜치를 보려면

git branch --no-merged

이 명령으로 나타나는 브랜치들은 merge 가 마무리되지 않음

 

 

 

 

 

https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-Rebase-%ED%95%98%EA%B8%B0

위와 같이, C4와 C3 커밋으로 나뉜 브랜치 둘을 병합하기 위해, merge 명령어를 사용할 수 있음
merge 명령어를 사용하면 새로운 커밋이 하나 생성되며 C4, C3 내용이 병합됨

새로운 커밋이 아닌, (fast-forward 하여 병합하기 위해) C4를 C3의 자손으로 만드는 방법을 rebase 라고 함
아래 순서대로 rebase 및 merge 진행

git checkout experiment
git rebase master
git checkout master
git merge experiment

rebase 진행 한 이후. https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-Rebase-%ED%95%98%EA%B8%B0

 

merge(fast-forward) 진행 한 이후. https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-Rebase-%ED%95%98%EA%B8%B0

 

 

 

 

Rebase를 하든지, Merge를 하든지 최종 결과물은 같고 커밋 히스토리만 다르다는 것이 중요
Rebase 의 경우는 브랜치의 변경사항을 순서대로 다른 브랜치에 적용하면서 합치고
Merge 의 경우는 두 브랜치의 최종결과만을 가지고 합침

 

 

+ Recent posts