혼자 간단한 프로젝트를 만들었을 땐 깃의 브랜치를 거의 사용하지 않았었다. 하지만 큰 프로젝트나 여러 사람이 참여하는 프로젝트에서는 브랜치가 매우 중요하다. 각각 독립적인 영역 안에서 마음대로 소스코드를 변경하기 위해서는 분리된 작업 영역에서 작업하고, 나중에 작업물을 합쳐야 한다. 브랜치를 다루는 핵심적인 명령어 몇 가지와 브랜치를 분기한 뒤 합칠 때 사용하는 merge와 rebase의 차이점을 정리해보겠다.
Branch 명령어
브랜치 생성 : 'step1'이라는 이름의 브랜치를 생성한다.
$ git branch step1
브랜치 확인 : 현재 생성되어 있는 브랜치 목록을 보여준다.
$ git branch
* master
step1
브랜치 이동 : 'step1' 브랜치로 이동
$ git switch step1
Switched to branch 'step1'
브랜치 삭제 : 'step1' 브랜치 삭제
$ git branch -d step1
Deleted branch step1 (was 04a144c).
만약 step1 브랜치에 변경 커밋이 있고 master 브랜치로 merge 되지 않았다면 삭제되지 않을 것이다. 그럴 땐 '-d' 대신 '-D'를 사용하여 강삭제를 해줘야 한다.
브랜치명 변경 : 'step1' 브랜치 'step2'로 변경
$ git branch -m step1 step2
브랜치 병합 시나리오
지금부터 merge와 rebase가 어떻게 다른지 브랜치를 나누고 커밋을 다르게 남기며 합쳐보면서 알아보겠다. 현재 브랜치는 master 브랜치 하나만 있는 상황이며 master 브랜치에서 MASTER.md 파일을 수정하고 커밋을 하나 남겼다.
뒤에 두 커밋은 무시하자. 'commit 1 in master' 커밋부터 확인하면 된다. 이제 이 상태에서 커밋을 2개 더 남기겠다.
이제 브랜치를 하나 더 생성해서 그 브랜치에서 다른 파일 작업을 해야 한다고 가정하자. 'step1' 브랜치를 생성하고 거기서 커밋 2개를 남겨보겠다.
'step1' 브랜치는 'commit 3 in master' 커밋부터 분기했고 다른 파일(STEP1.md)을 추가하여 자신의 작업을 진행하고 커밋을 2개 더 남겼다. 이제 여기서 master 브랜치에서 작업을 추가한다.
지금끼지의 상황을 정리하면 master 브랜치는MASTER.md 파일에서 작업하며 커밋 1, 2, 3, 6을 남겼고, step1 브랜치는 STEP1.md 파일에서 작업하며 커밋 3부터 분기하여 커밋 4, 5를 남겼다. 이제 브랜치를 합쳐야 할 때가 왔다.
Merge로 병합
master 브랜치에서 step1 브랜치의 내용을 가져오기 위에선 master 브랜치로 이동한 뒤 step1를 merge 하면 된다.
$ git merge step1
Merge made by the 'recursive' strategy.
STEP1.md | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 STEP1.md
그럼 step1 브랜치에서만 생성하고 작업했던 STEP1.md 파일이 master 브랜치 쪽에서도 생겨나서 브랜치가 병합되었다.
merge를 사용한 결과로 브랜치를 병합하는 커밋 로그가 master의 head에 새로 추가되었다. 브랜치가 분기해서 합쳐지는 로그가 그대로 남아있어서 꼼꼼하게 히스토리를 관리한다면 좋을 수도 있다. 하지만 규모가 큰 프로젝트에서 이렇게 분기들이 자잘하게 남아있으면 히스토리가 더러워지고 가독성이 떨어지게 된다. 이때 히스토리를 깔끔하게 한 줄로 관리하고 싶을 때 rebase 후 merge를 사용하면 된다.
Rebase로 병합
브랜치를 병합하기 전 상태와 똑같은 조건으로 만들기 위해 master에서 3개의 커밋을 남기고 step1 브랜치로 분기한 뒤 2개를 남긴 뒤 다시 master에서 하나를 더 남겨보겠다.
이제 여기서 rebase를 해보겠다. merge는 master 브랜치에서 했지만 rebase는 step1 브랜치에서 해야한다. rebase를 한다는 것은 말 그대로 base를 재설정한다는 의미이다. 현재 step1의 base는 커밋 9이다. (커밋 9까지 하고 분기했기 때문) 커밋 9였던 base를 master의 head인 커밋 12로 옮기는 작업이 바로 rebase이다.
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: commit 10 in step1
Applying: commit 11 in step1
step1에서 master를 rebase하자 마치 master에서 커밋 12를 남긴 뒤에 step1 브랜치로 분기해서 작업한 것처럼 히스토리가 하나로 합쳐졌다. 이제 이 시점에서 master에서 step1을 merge 한다.
그럼 보이는 것처럼 master 브랜치의 head도 제일 위로 올라왔다. merge로 병합했을 때와 달리 히스토리가 깔끔하게 한 줄로 합쳐졌다.
아직 협업 경험이 많지 않기 때문에 어느 상황에서 merge를 사용하고 rebase를 사용하는지 잘 와닿지는 않는다. 병합하는 과정에서 충돌도 많이 발생한다고 하는데 추후 그러한 충돌을 경험하게 되면 어떻게 해결했는지에 대해서도 포스팅해보고 싶다.
'Git' 카테고리의 다른 글
Git 정리 두 번째 Reset과 Revert (0) | 2022.02.19 |
---|---|
[Git] Upstream과 Origin이란? (0) | 2022.02.16 |
Git 정리 첫 번째 (로컬 저장소, init, add, commit, .gitignore, 개행문자 통일) (0) | 2022.02.12 |