일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- jupyter lab
- C++
- docker
- c#
- git
- c# 윈폼
- jupyter
- 포인터
- c언어
- 구조체
- 유니티
- vim
- 깃
- 다트 언어
- Data Structure
- Algorithm
- github
- C# delegate
- Flutter
- HTML
- Unity
- Houdini
- c# winform
- 플러터
- 도커
- Python
- gitlab
- dart 언어
- C언어 포인터
- c# 추상 클래스
- Today
- Total
nomad-programmer
[VCS/Git] git rebase: 브랜치 이력을 확인하면서 병합하기 본문
git 을 이용한 버전 관리 시스템의 작업 흐름은 평소에는 여러 개의 브랜치와 커밋 내역을 만들고, 마지막에 작업 내역을 확인하고 올바른 작업물만 병합하는 것이다.
git 의 특징 중 하나는 커밋 내역을 수정할 수 있다는 것이다. 하지만 수정할 수 있다고 해서 이미 원격 저장소에 푸시가 끝난 커밋 내역을 수정하는 것은 정말 특별한 상황이 아닌 이상 절대로 권장할만한 일이 아니다.
푸시하기 전에 git merge 명령을 이용해서 병합하면 충돌 해결 커밋이나, --no-ff 로 만든 병합 커밋을 남기게 된다. 이는 작업 흐름을 일관되게 파악하는 데는 깔끔하지 않다. 따라서 할 수 있다면 로컬 저장소에 있던 커밋을 깔끔하게 정리해서 푸시하는 것이 좋다.
그런 정리를 가능하게 하는 것이 git rebase 명령이다.
프로젝트 멤버가 세 명 이상이면 혹은 동시에 개발 중인 기능이 여러 개라면 브랜치가 세 개 이상으로 생성되는 일은 매우 흔한 상황일 것이다. 그럴 때마다 각자의 코드를 master 브랜치에 반영하면 커밋 내역 그래프가 매우 알아보기 어려울 것이다.
하지만 git rebase 명령을 사용하면 이를 깔끔하게 정리할 수 있다 (rebase는 단어 그대로 다시 base를 정리하는 것).
master 가 아닌 hotfix1 브랜치에서 rebase 명령을 실행하는 이유는 '(hotfix) rebase (onto) master' 라는 것이다.
"현재 작업 중인 브랜치의 base를 master로 다시 설정하라" 는 말이다.
git rebase 명령의 세 가지 옵션
명령 | 설명 |
git rebase --continue | 충돌 상태를 해결한 후 계속 작업을 진행할 수 있게 한다. |
git rebase --skip | 병합 대상 브랜치의 내용으로 강제 병합을 실행한다. 즉, 명령을 실행하면 master 브랜치를 강제로 병합한 상태가 된다. 또한 해당 브랜치에서는 다시 git rebase 명령을 실행할 수 없다. |
git rebase --abort | git rebase 명령을 실행 취소한다. 다시 git rebase 명령을 실행할 수 있다. |
명령을 실행하면 master 브랜치의 공통 부모까지의 hotfix1 브랜치의 커밋을 master 브랜치의 뒤에 차례대로 적용한다.
여기까지만이라면 단순하게 hotfix1과 master 브랜치가 따로따로 있는 것에 불과하게 된다. 말 그대로 hotfix1의 base를 다시(re) 설정한 것과 같은 효과이다.
병합해야만 비로소 master 브랜치에 hotfix1 브랜치가 반영된다.
그런데 git rebse 명령을 실행하면 무조건 fast-forward 가 가능하지만, 이런 경우 병합 커밋을 남기는 것이 좋다.
git merge <브랜치> --no-ff 명령을 실행해 fast-forward를 하지 말라는 옵션을 주어 병합을 실행한다.
* no fast-forward 는 일반적인 병합 시에도 해주면 좋다. 병합한 흔적을 명시적으로 커밋 그래프에 남기는 셈이니까
git rebase -i (커밋 내역 합하기)
git rebase 명령에는 활용도가 높은 옵션 -i 가 있다. i 는 interactive 의 i 이다. 한마디로 말하면 상호 작용하면서 리베이스할 커밋을 고르는 것이다.
위의 커밋 그래프도 꽤 완성도 높은 그래프이다. 그런데 커밋 내역과 작업 내역을 모두 합하면 더 깔끔하게 정리할 수 있다.
// 가장 최근 커밋 내역 두 개 합하기
git rebase -i HEAD~~
수정할 때의 원칙
- 남기는 커밋 메시지 앞에는 접두어로 pick 을 붙인다.
- 없애는 커밋 메시지 앞에는 접두어로 fixup 을 붙인다.
- 커밋 SHA-1 체크섬 값은 꼭 남겨두어야 한다.
- 기존의 커밋 메시지를 새롭게 수정할 수는 없다.
커밋 SHA-1 체크섬 값이 새롭게 바뀐 것을 확인할 수 있다.
즉, 여러 개 커밋 중에서 필요한 것을 고른 후에 새롭게 커밋하게 되는 것이다.
'VCS > Git' 카테고리의 다른 글
[VCS/Git] 프로젝트를 위한 협업 준비 규칙 (0) | 2019.12.05 |
---|---|
[VCS/Git] no fast-forward 전역 속성 추가 (0) | 2019.12.04 |
[VCS/Git] git checkout HEAD -- filename: 특정 파일을 최종 커밋 시점으로 되돌리기 (0) | 2019.12.03 |
[VCS/Git] git reset: 이전 작업 결과를 저장한 상태로 되돌리기 (0) | 2019.12.03 |
[VCS/Git] git revert: 공개된 커밋의 변경 내역 되돌리기 (0) | 2019.12.03 |