2021-03-04 Git을 사용하면서 알게되는 명령어 정리
git reset HEAD [file]
file 을 add 에서 취소. (뒤에 파일명 없으면 전체 add를 취소한다.)
git reset HEAD^
commit 취소하고 해당 파일들 unstaged 상태로 working directory에 보존.
git reset --hard HEAD^
commit 취소하고 해당 파일들 unstaged 상태로 working directory에서 삭제.
git commit --amend
바로 전 commit 수정.(vi 창 뜸)
이후
git push -f [remote] [branch]
remote branch에 강제로 push.
git reset HEAD@{commit number}
먼저 원하는 지점으로 commit을 되돌리고,
git commit -m "commit message"
거기에서 다시 commit을 한다.
git push -f [remote] [branch]
이후 remote branch에 강제로 push.
git reset --hard ORIG_HEAD
이전에 작업한 곳의 HEAD라는 뜻인 ORIG_HEAD로 되돌림.
git reset --merge ORIG_HEAD
pull이나 merge 시, ORIG_HEAD를 남기게 되는데 이를 이용.
작업 중인 공간(working space)을 잠시 다른 곳에 저장하고 다른 branch로 checkout 할 경우에는, git stash
를 이용한다.
git stash
는 현재 working space를 새로운 stash commit 형태로 저장한다.
다른 branch에서의 작업이 끝나고 돌아와 다시 작업공간을 불러오려면,
git stash list
로 stash 목록을 확인하고
git stash apply
또는 git stash apply [stash명]
로 했던 작업을 다시 가져온다.
이후 git stash drop
으로 가장 최근에 저장한 stash를 삭제한다.
(또는 git stash drop [stash명]
)
cherry picking - 협업 중 내가 원하는 지점부터 branch를 파서 내가 원하는 commit 만을 가져올 수 있음.
git cherry-pick [commit]
HEAD가 가리키고 있는 unit_test branch를 보면 팀장님의 커밋에서부터 branch를 파서 나의 master branch의 커밋 중 "Add Test::Account::Local" 커밋 만을 가져온 것을 볼 수 있다.
내가 사용하는 git cherry-pick 을 활용한 merge tip.
git fetch "git@gitlab.gluesys.com:examplecorrespondent.git" exbranch
로 상대 repository fetch 해옴.git checkout -b "examplecorrespondent/PROJECT-exbranch" FETCH_HEAD
FETCH_HEAD 를 이용하여 fetch해온 상대 repo의 branch로 checkout.git fetch origin
으로 내 origin fetch해옴.git checkout mybranch
내가 merge 할 branch로 checkout.git cherry-pick commitNumber
상대방의 branch에서 가져오고 싶은 commit number를 cherry-pick 으로 가져옴.git mergetool
로 merge conflict 해결.git commit -s
로 커밋 메세지 작성.release를 지속적으로 하고 있는데, 어느 시점부터 bug 가 생겨 program 이 돌아가지 않는다면, git bisect
를 이용하면 편하게 디버깅 할 수 있다.
예로, GMS Unit-Test 코드 작성 과정을 살펴보자.
이처럼 log가 존재할 때, Account::Local 의 test code 까지는 확실하게 unit-test 가 정상적으로 success 하게 돌아갔는데, 어느 시점인지는 몰라도 현재 unit-test가 잘 돌고 있지 않다면, 다음과 같이 git bisect를 이용한다.
먼저 확실히 정상적이었던 부분으로 checkout.
git checkout fc32821de
여기서 git bisect 를 start 하고, good
이라고 표기.
git bisect start
git bisect good
현재 안되는 code의 브랜치로 checkout 하여 bad
라고 표기.
git checkout unit_test
git bisect bad
그러면 자동으로 다음과 같이 HEAD가 good과 bad의 중간지점에 놓이게 된다. (git bisect 는 이진트리를 이용한다. (binary search))
HEAD의 위치에서 unit-test를 돌려보고, 성공적이라면 git bisect good
을, 실패하였다면 git bisect bad
를 표기한다. 성공이라고 가정하고 good을 표기한다면,
이 과정을 반복하다 보면, 마지막에 결과가 출력되며 어떤 commit이 문제였는지 알려준다.