GIT_1에서는 git의 기초를 다뤘다. -- 커밋을하고, 브랜치를 만들고, 소스 트리 여기저기를 돌아다니는 등. 이런 개념들을 아는 것만으로도 git repository의 힘을 90%이상 사용하고 개발자들이 필요로하는 작업의 대부분을 할 수 있다.
그 나머지 10% 기능이, 복잡한 작업(또는 작업중 막혔을때) 중에 꽤 유용하다. 이제 배워 볼 다음 개념은 "작업을 여기저로 옮기기"이다. 다시 말해, 개발자들의 언어로 "이 일은 여기에, 저 일은 저기에 두고 싶어" 정확하고 우아하고 유연하게.
Git 체리-픽 (Cherry-pick)
사용법: git cherry-pick <Commit1> <Commit2> <...>
-현재 위치(HEAD) 아래에 있는 일련의 커밋들에 대한 복사본을 만들겠다는 것을 간단히 줄인 말이다.
-Git 체리-픽은 원하는 커밋이 무엇인지 알때(각각의 해시값도) 아주 유용하다.
main 으로 복사하고 싶은 작업이 있는 브랜치 side가 있다.
git cherry-pick c2 c4
C2와 C4 커밋을 원했고 git이 우리가 원하는 곳 바로 밑에 떨어뜨려 줬다.
Git 인터렉티브 리베이스(Interactive Rebase)
원하는 커밋을 모르는 경우, 리베이스할 일련의 커밋들을 검토할 수 있는 가장 좋은 방법이다.
인터렉티브 리베이스가 의미하는 뜻은 rebase 명령어를 사용할 때 -i 옵션을 같이 사용한다는 것이다.
이 옵션을 추가하면, git은 리베이스의 목적지가 되는 곳 아래에 복사될 커밋들을 보여주는 UI를 띄운다. 각 커밋을 구분할 수 있는 각각의 해시들과 메시지도 보여준다.
"실제" git 에서는 UI창을 띄우는것 대신에 vim과 같은 텍스트 편집기에서 파일을 연다.
인터렉티브 리베이스 대화창이 열리면 할 수 있는 3가지!
- 적용할 커밋들의 순서를 UI를 통해 바꿀수 있다.
- 원하지 않는 커밋들을 뺄 수 있다. 이것은 pick을 이용해 지정할 수 있다.
- 커밋을 스쿼시(squash)할 수 있다 = 커밋을 합칠 수 있다
git rebase -i HEAD~4를 하면 아래와 같은 창이 나온다.
Git이 UI를 통해 명시한 그대로 커밋들을 복사했다.
- 커밋을 스쿼시(squash)할 수 있다 = 커밋을 합칠 수 있다
개발 중에 종종 눈에 잘 띄지 않는 버그를 찾아서 해결하려고, 어떤 부분의 문제인지를 찾기 위해 디버그용 코드와 화면에 정보를 프린트하는 코드 몇 줄 넣는 상황이 생긴다.
디버깅용 코드나 프린트 명령은 그 브랜치에 들어있어 마침내 버그를 찾아서 고치고, 원래 작업하는 브랜치에 합치면 된다.
이제 bugFix브랜치의 내용을 main에 합쳐 넣으려 하지만, 한 가지 문제가 생긴다. 그냥 간단히 main브랜치를 최신 커밋으로 이동시킨다면(fast-forward) 그 불필요한 디버그용 코드들도 함께 들어가 버린다는 문제가...
이 문제를 해결할 수 있는 방법은 2가지가 있다.
1. git rebase -i : 개별 커밋을 골라서 HEAD위에 떨어뜨릴 수 있다.
2. git cherry-pick : 어떤 커밋을 취하거나 버릴지를 선택할 수 있다. 커밋의
문제!!
newImage와 caption 브랜치에 각각의 변경내역이 있고 서로 관련이 있어서, 저장소에 차례로 쌓여있는 상황과 이전 커밋의 내용을 살짝 바꿔야하는 골치아픈 상황이 있을 수 있다. 이번 문제는 디자인 쪽에서 작업이력(history)에서는 이미 한참 전의 커밋 내용에 있는 newImage의 크기를 살짝 바꿔 달라는 요청이다.
해결방법
- git rebase -i 명령으로 우리가 바꿀 커밋을 가장 최근 순서로 바꾸어 놓는다.
- git commit --amend 명령으로 커밋 내용을 정정한다.
- 다시 git rebase -i 명령으로 이 전의 커밋 순서대로 되돌려 놓는다.
- main을 지금 트리가 변경된 부분으로 이동한다.
