1. 1개의 커밋만 가져오기
개발 중에 종종 이런 상황이 생깁니다: 눈에 잘 띄지 않는 버그를 찾아서 해결하려고, 어떤 부분의 문제인지를 찾기 위해 디버그용 코드와 화면에 정보를 프린트하는 코드 몇 줄 넣습니다.
디버깅용 코드나 프린트 명령은 그 브랜치에 들어있습니다. 마침내 버그를 찾아서 고쳤고, 원래 작업하는 브랜치에 합치면 됩니다!
이제 bugFix브랜치의 내용을 main에 합쳐 넣으려 하지만, 한 가지 문제가 있습니다. 그냥 간단히 main브랜치를 최신 커밋으로 이동시킨다면(fast-forward) 그 불필요한 디버그용 코드들도 함께 들어가 버린다는 문제죠.
대화형 (-i 옵션) 리베이스(rebase)로는 어떤 커밋을 취하거나 버릴지를 선택할 수 있습니다. 또 커밋의 순서를 바꿀 수도 있습니다. 이 커맨드로 어떤 작업의 일부만 골라내기에 유용합니다.
체리픽(cherry-pick)은 개별 커밋을 골라서 HEAD위에 떨어뜨릴 수 있습니다.
git rebase -i HEAD~3 // HEAD기준 3개를 순서바꿈 혹은 omit
git branch -f main bugFix // main을 bugFix 브랜치로 옮김.
2. 커밋들 갖고 놀기
newImage와 caption 브랜치에 각각의 변경내역이 있고 서로 약간 관련이 있어서, 저장소에 차례로 쌓여있는 상황입니다.
이전 커밋의 내용을 살짝 바꿔야하는 골치아픈 상황에 빠지게 됩니다. 이번에는 디자인 쪽에서 우리의 작업이력(history)에서는 이미 한참 전의 커밋 내용에 있는 newImage의 크기를 살짝 바꿔 달라는 요청이 들어왔습니다.
git rebase -i caption~2 // caption부터 3개를 순서 * omit을 바꿈
git commit --amend // commit내용 정정
git rebase -i caption~2 // 정정 이후 순서 다시 원상복귀
git branch -f main caption // main브랜치를 caption으로 강제 옮기기
(HEAD로 해도 무방)
3. 커밋 갖고 놀기 (2)
앞선 방법을 사용할 경우 rebase중 충돌이 일어날 수 있다.
한가지 문제는 순서를 꽤 많이 바꿔야한다는 점인데요, 그러다가 리베이스중에 충돌이 날 수 있습니다. 이번에는 다른 방법인 git cherry-pick으로 해결해 봅시다.
git checkout main / main브랜치로 HEAD를 옮김
git cherry-pick c2 / c2를 옮김
git branch -f main c1 / main브랜치를 c1 커밋으로 옮김 ( 위로 )
git cherry-pick c2' c3 / c2'와 c3를 옮겨 새로운 커밋을 만듦
4. git tag
여러분은 여러분의 프로젝트의 역사(작업 이력)에서 중요한 지점들에 영구적으로 표시를 할 방법이 없을까 궁금할것입니다. 주요 릴리즈나 큰 브랜치 병합(merge)이 있을때가 그런 상황이겠군요. 이런 상황에 커밋들을 표시할 브랜치보다 영구적인 방법이 있을까요?
Git 태그는 특정 커밋들을 브랜치로 참조하듯이 영구적인 "milestone(이정표)"으로 표시합니다.
Git 태그는 커밋들이 추가적으로 생성되어도 절대 움직이지 않는다는 것입니다.
git tag v0 c1 // c1에 v0라는 태그를 만든다.
git tag v1 c2 // c2에 v1이라는 태그를 만든다.
git checkout v1// v1태그로 체크아웃 한다.
5. get describe
git에는 여러분이 가장 가까운 "닻(태그)"에 비해 상대적으로 어디에 위치해있는지 describe(묘사)해주는 명령어가 있습니다. 이 명령어는 git describe 입니다!
git describe <ref> 형태로 사용. ref 안에는 어떠한 커밋이든 가능.명령어의 출력은 다음과 같은 형태로 나타납니다:
<tag>_<numCommits>_g<hash>tag는 가장 가까운 부모 태그를 나타냅니다. numCommits은 그 태그가 몇 커밋 멀리있는지를 나타냅니다. 는 묘사하고있는 커밋의 해시를 나타냅니다.
git describe c6
-> v1_2_gC6 // c6가 v1태그에서 2칸 떨어져있다. 