안녕하세요. 이번 시간에는 기타 Git 명령어들에 대해 알아보겠습니다.
사실 지금까지 한 것들만으로도 프로젝트를 돌릴 수 있습니다만, Git에는 여러 유용한 기능들이 있기 때문에 추가적으로 몇 개만 더 알아보도록 하겠습니다.
이 명령어는 이름이 독특하죠? 체리를 고른다는 뜻인데요. 여기서 체리는 commit을 의미합니다. 다른 브랜치의 commit 중 하나를 쏙 골라서 현재 브랜치에 넣는 겁니다. merge나 rebase는 다른 브랜치를 통째로 가져오는 데 비해, 다른 브랜치의 원하는 commit 한 개만 가져올 수 있습니다.
이 기능이 왜 필요한 지 처음에는 잘 몰랐습니다. 하지만 필요한 경우가 있더라고요. 간단한 저의 예를 들어보겠습니다.
저는 현재 A라는 에디터를 사용해서 포스팅을 하고 있는데, B라는 에디터로 전환하고자 하는 상황입니다. 그래서 새로운 editor라는 브랜치를 만들어서 테스트하고 있습니다. 새로운 에디터도 넣고, CSS 바꾸는 등 여러 작업을 하고 있는데, 기존 master 브랜치에 새로 바꾼 CSS 작업만 가져오고 싶습니다.
merge나 rebase로 editor 브랜치를 통째로 가져오려니 아직 새로운 에디터가 완성이 안 된 상태입니다. 이럴 때 cherry-pick으로 CSS를 바꾼 commit만 쏙 빼오는 겁니다.
git cherry-pick [commit명]
commit명이 문제인데 commit명은 우리가 commit할 때 썼던 메시지가 아닙니다. 바로 Git 자체에서 붙여주는 고유값인데 이게 랜덤한 문자라서 외우기 힘듭니다. 그나마 git log하면 볼 수 있습니다.
노란 부분의 79945~b16e8이 바로 commit의 이름입니다. 황당하죠? 저 긴 것을 다 써주면 됩니다... 저게 싫다면 밑에 git tag를 참조하세요. 아니면 GUI 도구를 사용하면 쉽게 cherry-pick할 수 있습니다.
commit에 태그를 붙이는 기능을 합니다. 태그란 꼬리표로 commit에게 별명을 지어주는 겁니다. 방금 전 cherry-pick을 할 때 commit명이 무시무시했죠? 랜덤한 문자열이니까요. 이런 것에 이름을 붙여주면 해당 commit을 특정하기 쉬워집니다.
주로 새로운 버전이 나왔거나 특정 기능을 가진 commit에 tag를 붙여줍니다. git tag -a v1.0.0 이렇게 하면 git cherry-pick v1.0.0으로 선택할 수 있는거죠.
태그 삭제는 git tag -d 태그명입니다.
git pull 기억나시나요? 하도 예전에 해서 까먹으셨을 수도 있겠네요. git pull은 서버의 변경점을 클라이언트로 내려받는 명령어입니다. 그런데 git pull은 사실 두 개의 단계로 구성되었습니다. 바로 git fetch와 git merge입니다.
git pull을 하는 순간 내부적으로는 저 두 개의 명령어가 호출되는 데 git fetch는 서버의 변경점을 별개의 브랜치로 만드는 것이고, git merge는 그 브랜치를 합치는 겁니다. 이제 이해가 가죠? git fetch 명령어만 실행하면 merge하지 않고 FETCH_HEAD라는 별개의 브랜치에서 변경점을 확인할 수 있습니다.
지금까지 commit 내역을 보려면 git log를 했죠. 하지만 눈이 너무 아픕니다. 여러분들은 다른 대안을 찾기 위해 노력하셨을 텐데요. 간단하게 git shortlog하면 됩니다. commit 메시지만 추려서 보여주거든요. 하지만 최고의 방법은 GUI를 사용하는 겁니다.
stash는 알아두면 편한 명령어입니다. 현재 변경점을 저장할 수 있습니다. commit과는 다른 의미의 저장인데요. 한 브랜치에서 작업을 하다가 잠깐 다른 브랜치에서 작업할 일이 생겼을 때에 주로 사용합니다. 현재까지의 변경사항을 저장하고 다른 브랜치로 넘어갔다가, 다시 돌아왔을 때 복구할 수 있습니다.
git stash 명령어를 사용하면 현재 변경사항들이 저장되고, git status 내역이 비워집니다. stash한 것들은 git stash list하면 확인할 수 있습니다.
이제 다른 작업을 하고 돌아와서 저장했던 stash를 복구해보겠습니다. 간단히 git stash apply하면 최근에 저장한 stash가 복구됩니다.
참고로 꼭 처음에 저장했던 브랜치에 복구할 필요는 없습니다. 다른 브랜치에 해도 상관없다는 뜻이죠. 대신 충돌이 일어날 수는 있습니다.
다음 시간에는 Github Flow에 대해 알아보겠습니다!