2020. 7. 16. 00:35ㆍ부딪히며 배우는 GIT/GIT 명령어
git reset
리셋 작업은 크게 3가지로 나눌 수 있다. 하나는 add 가 끝난 시점으로 돌아가는 soft, 둘째는 staged 파일들(추적 중)과 untracked 파일들이 섞인 시점으로 돌아가는 mixed, 아예 그냥 이전 커밋 상태로 돌아가는 hard 가 있다. reset을 할 때 플래그로 이 옵션을 넣어주면 적용된다. (--soft, --mixed, --hard)
Tip: 되도록이면 hard는 주지 않는 것이 좋다. 기존에 작업했던게 임시로라도 남아있지 않고 그냥 다 날아가 버리기 때문이다. 아니면 git stash 를 통해 임시 저장을 수행한 다음 해주는 것이 좋다.
git stash
작업을 하다가 잠깐 작업을 중단해야하는 상황이 생겼는데, 커밋 내역을 만들기에는 애매할 때 쓴다. 해당 브랜치가 아닌 어떤 임시 저장소에 지금 코드의 내용을 모두 저장한다.
git rebase
rebase 는 외부 브랜치, 그러니까, feature 입장에서 행해지는 동작이다. 그리고 rebase의 'base'는 feature 브랜치와 마스터 브랜치의 공통 커밋, 즉 분기점을 의미한다. 즉, 'rebase'한다는 것은 base 를 바꾼다라는 의미이고, 즉 이 base를 마스터 브랜치의 최신 커밋으로 바꾼다는 말이다. 그리고 이 과정은 다음과 같다.
- git rebase master 실행
- 깃의 임시 저장소에 feature 의 모든 커밋들이 저장됨
- 마스터의 최신 커밋으로 이동함. 임시 저장소에 저장되어 있는 커밋들(패치라고 부름)을 마스터 브랜치의 최신 커밋과 병합시킨다.
- 이때 패치의 가장 이전 커밋부터 하나하나 차례대로 병합시킨다. 병합시키면서 병합된 내용을 마스터 커밋의 최신 커밋 옆에 줄줄히 붙인다(마스터의 최신 커밋과 feature 의 최초 커밋과 결합 → 결합된 내용으로 커밋내역을 마스터에 생성 → 결합된 내용과 feature 의 두번째 커밋과 결합....반복). 이렇게 만들어진 커밋의 흐름이 feature 커밋의 전체 커밋 흐름으로 대체된다. 이 전체 과정이 리베이스이다.
- 이때 각 병합 단계에서 충돌이 일어나면 그 충돌을 해결한 후 git rebase —continue 를 수행해주어야 한다. 모든 충돌되는 단계에서 이를 수행해주어야 한다.
merge 와의 차이점
- merge 는 master에서 실행한다. feature 브랜치는 그대로 둔 채로, feature 브랜치의 HEAD와 master 브랜치의 HEAD 를 병합하는 기능이다. 이때 master 브랜치에 존재하지 않는 커밋이 외부 브랜치에 있다고 해도 그냥 무시한다. merge 를 수행하면 merge 의 결과물이 외부 브랜치와 해당 브랜치 둘 다의 커밋 흐름에 남는다.
- rebase 를 하게 되면 master 와 feature 의 분기점이 되는 해당 커밋 후 병합으로 생성된 커밋들만이 이어붙여진 브랜치 흐름이 만들어진다. 즉, 병합 이전의 내용들은 다 날아가게 된다.
** FAST-FORWARD 란?
: master 브랜치가 아무 변경 없이 가만히 있는데 그 master 브랜치를 바탕으로 생성된 다른 feature 브랜치가 계속해서 커밋을 쌓아나가고 있을 경우, master에서 feature 를 병합하려 할때 사실상 feature 브랜치의 내용이 마스터를 포함하게 되기 때문에 마스터의 Head를 feature 의 Head 로 옮겨버리는 간단한 작업만이 일어난다. 이것을 FAST-FORWARD 라고 한다. 즉 FAST-FORWARD 는 동일 내용이 포함되는 브랜치끼리는 브랜치 이동만으로 병합이 이루어져서 따로 commit이 생성되지 않는 경우를 의미한다.
'부딪히며 배우는 GIT > GIT 명령어' 카테고리의 다른 글
git stash 명령어의 활용 (0) | 2020.12.02 |
---|