TIL) cherry-pick 외 git 각종 취소 명령어들, ORIG_HEAD

1. Cherry-pick

좋은 체리와 나쁜 체리를 골라서 최상의 체리를 골라내는 어원이라고 한다.

깃에서는, 다른 브랜치의 필요한 코드(커밋) 을 뚝 때와서 붙이고 싶은 브랜치에 붙일 때 사용한다.

존재는 알아도, 잘 몰랐던 이유가 잘 쓸 일이 없어서 였는데 아는 만큼 보인다고 요즘 쓸 일이 슬슬 생기기 시작한다.

 

 

체리픽을 하기 위해 먼저 준비할 것은, 가져오고 싶은 커밋(어떤 브랜치든지)의 해시값을 알아내는 것이다.

이는 뭐 git log 명령어로 쉽게 알 수 있다.

 

 

이후 코드를 붙여넣고 싶은 브랜치로 가서 아래 명령어를 실행한다.

git cherry-pick <해시값> // 커밋 하나 체리픽
git cherry-pick <해시값> <해시값> // 커밋 여러개 체리픽
git cherry-pick <해시값>..<해시값> // 앞의 해시 커밋 다음 커밋부터 뒤의 커밋까지 범위로 체리픽
git cherry-pick <해시값>^..<해시값> // 앞의 해시 커밋포함부터 뒤의 커밋까지 범위로 체리픽

해시값은 원래 40글자 (SHA-1 의 160비트 = 20바이트를 16진수로 바꾸면 40글자) 이지만, 하나의 리포지토리에서는 왠만하면 앞 몇글자만 따도 커밋을 특정지을 수 있다. 위 명령어에서도 해시값을 여서일곱자만 붙여넣어도 잘 동작한다.

 

 

이 명령어들을 치면, 체리픽으로 가져올 커밋들을 우리 브랜치에 커밋 로그 뒤로 때려박는게 아니라,

시간 순서에 맞게 커밋들을 끼워넣게 된다.

 

이 과정에서 Merge 와 같이 충돌이 일어날 수 있다. (코드를 합치는 과정이니 당연하다.)

 

merge 때에는 충돌을 해결 후 commit 을 날렸지만, 여기서는 조금 다르다.

 

 

1-1. cherry-pick 충돌 후

1. 충돌을 해결했을때 ->

git add . 
git cherry-pick -continue

 

2. 충돌나서 체리픽하기 이전으로 돌리고 싶을 떄 ->

git cherry-pick -abort

 

1-2. 머지 커밋을 cherry-pick

git cherry-pick m 1 <머지 커밋>

 

1-3. 주의점 ?

주의점이라 해야 할 까. 뭐 생각할 점은, 체리픽이 무분별하게 되다 보면 같은 커밋이 여러개 생긴다.

체리픽이 된 원본이 뭔지 찾기 힘들어진다.

체리픽 원본이 필요한 상황은 아직 겪지 못했지만, 의식하면서 사용하자.

 

[cherry-pick 참고]

https://cselabnotes.com/kr/2021/03/31/56/

git 명령어 : git cherry-pick - 삐멜 소프트웨어 엔지니어

 

[git 파헤치기] - 공부 한번 했던거같은데 또 보니 새롭다... 링크 저장해두고 다음에 공부해보자.

https://medium.com/happyprogrammer-in-jeju/git-%EB%82%B4%EB%B6%80-%EA%B5%AC%EC%A1%B0%EB%A5%BC-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90-1-%EA%B8%B0%EB%B3%B8-%EC%98%A4%EB%B8%8C%EC%A0%9D%ED%8A%B8-81b34f85fe53

Git 내부 구조를 알아보자 (1) — 기본 오브젝트

https://tecoble.techcourse.co.kr/post/2021-07-08-dot-git/

.git 내부 구조 파헤치기

 

 

 

 

 

 

2. git 각종 취소 명령어

• add 취소 (unStaging)

add 파일 취소 : git reset HEAD [스테이지에 올라간 파일]
add 전체 취소 : git reset HEAD 

 

• commit 취소

git reset HEAD^ : ^ 갯수가 헤드로부터의 커밋 갯수이다.
(ex git reset HEAD^^^^)

커밋 취소시 옵션을 세가지 줄 수 있음

• --soft : 커밋 대상이 된 파일들이 스테이징 상태로 취소됨. (add 한 상태)
• --mix : 커밋 대상이 된 파일들이 언스테이징 상태로 취소됨. (add 안한 상태)
• --hard : 커밋 대상이 된 파일들이 삭제되며 완전히 리셋됨. (파일 작성도 하기 전 상태)

 

 

• push 취소

git revert [커밋 해시]

 

 

 

사실 reset, revert 가 commit 과 push 로 나눈 것이 이상하긴 하다.
reset 은 커밋 자체를 돌리는 것이고, (시간을 돌리듯)
revert 는 커밋을 되돌리는 커밋을 하나 더 날리며 원상복구 시키는 것이다.

깃을 이용한 협업에서 이미 push 된 커밋을 바꾸는 행위는 매우 위험하다.
하나의 형상을 100 명이서 쓰고 있었는데, 임의로 커밋을 바꿔서 푸시하면 100명이 나름 각각의 코드작업을 하고 푸시하려면 머지과정에서 에러가 날 것,,
그래서 푸시된 코드는 revert 한 커밋을 날려야 한다는 의미로 위처럼 나누어 정리.

http://www.devpools.kr/2017/01/31/%EA%B0%9C%EB%B0%9C%EB%B0%94%EB%B3%B4%EB%93%A4-1%ED%99%94-git-back-to-the-future/

개발바보들 1화 - git "Back to the Future"

 

 

 

 

 

 

2. 특수한 HEAD

HEAD : 최신 commit 을 가리키는 기본 헤드.

FETCH_HEAD : 마지막 git fetch 명령으로 원격 저장소에서 가져온 브랜치의 HEAD.

MERGE_HEAD : git merge 를 수행할 때, 브랜치에 merge 할 commit.

CHERRY_PICK_HEAD : git cherry-pick 수행할 때, cherry pick 한 commit.

ORIG_HEAD : HEAD 의 위치를 변경하는 명령을 수행했을 때, 직전의 HEAD 의 위치를 가리킨다.

 

ORIG_HEAD 는 유용하게 쓰이는데,

reset 명령을 잘못했거나,

merge 를 잘못했거나,

pull 을 잘못한 경우 유용히 사용할 수 있다.