자주쓰는 깃 명령어 모음

 

 

처음 코딩을 할때는 혼자 깃허브 저장소를 사용하다보니

git commit -m 'First Commit'
git push origin master

이 수준의 명령어를 반복하는게 전부였다.

 

협업을 할 기회가 없으니 미루고 미루다 결국 아무것도 모른채 회사에 들어가서 깃허브를 마주하게 되었다.

처음에는 커밋이 꼬이는 일이 참 많았는데, 

 

"그거 revert 해서 새로 pr 올리세요"

"아 rebase 하면 돼요"

"conflict 났으니 merge 해주세요"

"새로 브랜치 파서 cherry-pick 하고 올려주세요"

 

등등이 나에겐 외계어 처럼 들렸다. 약 1년이 지난 지금은 다행히 편하게 깃을 사용할 수 있다(그렇다고 잘 다루는건 아니지만).

혹시라도 잠깐 안쓰면 또 까먹을 수 있으니, 평소에 일상적으로 쓰는 명령어를 용도와 함께 간단하게 기록했다.

 

* 제가 익숙해진 방식일뿐 무조건 이런 상황엔 이렇게 해야한다 류의 내용은 아닙니다.

 

일반적인 Git 사용

git pull
git checkout -b [새로 만들 브랜치명]
git add .
git commit -m '커밋 메시지'
git push origin [push할 브랜치명]

숨쉬듯이 쓰게되는 일반적인 내용. 

현재 브랜치 내용 업데이트 -> 새로운 브랜치 만듦 -> 작업이후 수정된 파일 추가 -> 커밋 메시지 입력 -> 원격 저장소에 push

 

원격 저장소에 있는 branch 가져오기

git remote update

git pull 을 하면 현재 checkout 되어있는 브랜치의 내용만 업데이트가 된다.

하지만 종종 다른 사람이 작업한 브랜치를 접근해야할 때가 있는데, 그럴때는 update 한 이후 그 브랜치로 checkout 해주면 된다

 

현재 수정 내용 임시 저장

git stash

# 가장 최근 stash 적용 
git stash apply
# 리스트 확인
git stash list
# 특정 stash 적용 ex. stash@{1}
git stash apply [stash 명]

 브랜치를 옮겨가며 작업하는게 익숙하지 않으면 가끔 checkout 하려다 막히는 상황이 생긴다.

이는 커밋되지 않은 수정 내용이 있기 때문인데, 커밋을 해두면 좋겠지만 좀 애매할 경우 stash를 사용해서 임시저장이 가능하다.

git stash 를 사용해서 잠시 저장해둔 뒤 다시 돌아와서 git stash apply 를 하면 원래대로 돌려놓을 수 있다(기존 작업하던 곳이 아닌 다른 브랜치에 apply하는것도 가능).

stash가 여러개 쌓여있을 경우 list 명령어를 통해 확인한 뒤 특정 stash를 불러오는게 가능하다.

 

현재 수정 내용 임시 저장 (꼼수 ver)

git add .
git commit -m '임시저장(내 맘대로 써두기)'
# ... 다른 작업 이후 브랜치로 돌아옴
git log
# 직전 커밋을 취소함
git reset HEAD^

위의 stash를 알고 처음엔 엄청 좋아했는데,

여러 브랜치를 오가며 작업을 하다보니 stash가 많이 쌓여 매번 특정 stash를 찾고 apply 하는 일이 귀찮아져 버렸다. 

그래서 요즘에는 아예 작업하던 브랜치에 커밋을 해버린다. 그리고 다시 브랜치에 돌아왔을때 매번 log를 확인해서 임시저장된 내용이 있으면 reset을 한번 해주고 사용한다.

단점은, reset을 잊으면 임시저장용이었던 커밋 메시지가 깃허브에 기록되는 참사가 생길 수 있음!

아마 커밋을 잘게 쪼개는데 익숙한 능력자라면 이런 방법도 필요없을것 같다. 시행착오를 많이 겪다보니 생긴 습관.

 

로컬에서 수정한 내용 reset하기

# 로그 확인
git reflog
git reset [돌아갈 커밋명 or HEAD@{해당하는 숫자}]

위에서 reset HEAD^ 를 사용해서 직전 커밋을 리셋했는데, 원하는 리셋 위치가 있을땐 이 코드를 사용한다.

reflog 에 매순간 커밋명과 HEAD@{숫자} 가 기록되어 있으니 확인 후 입력해주면 된다. 

보통 나는 HEAD^^^ 이런식으로 세단계 전으로 가는 편이다. 물론 로컬에서만..

 

리모트에 잘못 올라간 커밋 지우기

git revert [커밋명]

보통 로컬에서 잘못된 커밋은 바로 reset을 해도 되지만, 이미 원격 저장소에 올라간 뒤에 그 커밋을 reset을 하는건 매우 위험하다.

reset은 아무 기록없이 커밋이 지워지기 때문이다.

누군가 이미 그 커밋을 pull 해서 작업을 했다면 나중에 conflict이 생기거나, 모르는사이 reset한 코드가 다시 살아나 머지되어 있을 수 있다.

그러므로 안전하게 revert를 해서 push를 하자!

 

merge conflict 없애기

git rebase [push가 들어갈 브랜치명]
git merge [push가 들어갈 브랜치명]

깃허브에 PR을 올릴 때, 같은 부분을 작업한 다른 분의 커밋이 먼저 머지되면 merge conflict로 merge가 막히는 경우가 종종 생긴다.

이때 해결법은 여러가지가 있겠지만 나는 주로 push를 하기 전엔 미리 rebase를 하고, 이미 리뷰를 받는 중이면 merge를 한다.

rebase는 지금 올린 PR이 마치 가장 최신 업데이트 이후에 브랜치를 따서 작업한 것처럼 깔끔하게 만들어준다. 대신 이미 커밋한 내용들을 줄줄이 수정해야 할수도 있다.

한편 merge는 현 상황에서 conflict 나는 부분만 수정해서 새로운 커밋을 만들 수 있다.

초창기엔 잘 모르고 rebase를 많이 썼는데, 요즘엔 대부분의 경우 merge가 편해서 merge를 쓴다.   

 

필요한 커밋만 골라내기 (cherry-pick)

git cherry-pick [커밋명1] [커밋명2] [...]

커밋을 한참 하다가 문제가 생겨 이력을 보면, 일부만 살리고 나머지는 버리고 싶은 생각이 든다. 이럴때는 cherry-pick이라는 강력한 녀석이 있다. 옛날엔 이것도 이해를 못해서 써먹지를 못했다.

예전에는 이상한 커밋이 끼어있어서 그걸 빼야 하는 경우나, 잘못된 브랜치에서 작업중이었을 경우 새로 브랜치를 만들어서 작업한 내용만 빼오는 경우에 많이 사용했다.

요즘은 좀 큰 덩어리의 작업을 할 때 많이 사용한다. 작은 덩어리 하나를 PR 올려둔 상태에서 계속 남은 작업을 하고, PR이 머지되면 master를 pull한 새로운 브랜치를 만든 이후 했던 작업을 붙여서 바로 다시 새로운 PR을 올린다. 머지 될때까지 기다리는 비효율을 줄일 수 있다.

 

 

짧게 쓰려던 글이 너무 길어졌다. 사실 파고들면 내용이 훨씬 많겠지만 일단 이정도만 정리해두고 오늘은 끝!