git merge, rebase, cherry-pick, reset, Squash and merge 정리

[merge, rebase]

공통 목적 : PR전, 작업 브랜치가 대상 브랜치와 fast-forward상태가 되도록 하기위함

merge
두개 혹은 세개의 브렌치를 활용하여 새로운 commit을 생성 후 현재 브랜치에 덧붙임
3-way merge : 총 세가지의 commit(브랜치a,b,공통조상)을 활용하여 새로운 commit을 생성 후 현재 브랜치에 덧붙임
fast forward merge : merge의 피대상(base) 브랜치와 대상(changed) 브랜치가 합칠때 피대상 브랜치의 변화가 없을 경우 피대상 브랜치의 포인터만 대상브랜치로 옮겨짐

*git merge -X [ours or theirs] 브랜치명 ([내것 or 상대것]으로 conflict 없이 auto merge, 단 기존 파일 delete 처리 필요)

rebase
대상(ㄴ) 브렌치를 현 base로 두고 이전 base에서 피대상(ㄱ) 브렌치까지 이어진 commit을 현 base부터 이어 덧붙임
rebase 후 [대상(ㄴ) 브랜치 혹은 이전 base 브랜치로] wd를 바꾸고 commit이 이어짐이 완료된 피대상(ㄱ) 브랜치로 fast forword merge하여 commit 기록 가능

*git hub는 pull 진행시 rebase가 진행됨

쓰이는 상황을 위한 비교관점 : 작업 히스토리의 유지상태 vs clean상태  

선 상황. checkout 후 PR 시점이 길지 않은 경우 : PR 가능성 유무 체크 후 불가능 상황일때 밑의 상황중 하나를 선택하여 진행

A 상황. 작업 브렌치가 하나로 통합되기에 커밋이 과하게 많아서 합쳐질 경우 각 커밋 단계를 가지는거 보다 가독성이 떨어진다

>> merge

B 상황. 작업 브렌치에 커밋이 적당히 있어 합쳐져도 읽을만한 가독성이 유지되기 때문에 깔끔한 커밋 히스토리를 남기고 싶다

>> rebase



[cherry-pick]

대상(ㄴ)브랜치의 특정 commit을 피대상(ㄱ) 브랜치에 적용시킬때 사용



[reset -hard, -soft]

hard : 커밋 id의 특정상황의 파일과 디랙토리 상태가 적용
soft : 커밋 id의 특정상황의 파일과 디랙토리 상태가 적용 + 커밋 id의 특정상황 이후 추가되거나 바뀐 사항은 stage됨



[Squash and merge in Git Hub]

기존 merge와 달리 PR시 반영될 커밋들을 하나로 합쳐 새로운 커밋으로 만들고 대상 브랜치에서만 참조됨

 

[Ref]

merge rebase ref
https://www.tuwlab.com/ece/22218 
https://velog.io/@godori/Git-Rebase
https://milooy.wordpress.com/2018/10/25/git-rebase-or-merge-commit/

cherry-pick ref
https://imasoftwareengineer.tistory.com/7

Squash and merge

https://meetup.toast.com/posts/122