git merge vs git rebase (1)

git merge와 git rebase의 차이점에 대해서 알아보고, 실무에서 어떻게 사용했는지 기록을 남긴다

 

intro)

 

먼저 내가 실무에서 사용했던 레퍼지토리의 구성은 다음과 같았다

 

가장 중요한 브랜치는 develop 이고, 이 develop 브랜치를 원본으로 각 3개의 브랜치를 만들어서 동시에 작업하게 되는

상황이다

 

- develop => feature(기능)

- develop => hotfix(버그수정)

- develop => refactor(코드개선)

 

그림으로 보면 다음과 같다

 

 

만약 git merge를 사용한 경우 대략 아래와 같은 구성이 될 것이다

위 그림을 보면 feature 브랜치에서, hotfix 브랜치를 병합하고 또 refactor 브랜치를 병합시킨다

 

이렇게 feature 브랜치에 모두 작업이 모아졌고, 마지막으로 develop 브랜치로 이동해서 feature 브랜치를 병합시키면

 

여태까지의 작업 결과물과 그 이력이 develop에 모두 반영이 되는 구조이다.

 

merge도 충분히 협업하는데에 무리가 없지만,

 

위와 같이 "Merge branch..." 로 시작하는 커밋이 만들어지는 점이 단점이라고 볼 수 있다

 

커밋이 만들어 진다는 뜻은

 

git merge는 병합 대상 브랜치의 커밋을 병합하는 브랜치의 끝에 추가하므로,

 

병합 후에도 두 브랜치의 커밋 기록이 유지된다는 뜻이다

 

이게 왜 단점이냐면 바로 이 "Merge branch..." 커밋때문에 작업이력이 모두 하나의 커밋으로 합쳐져 있어서

 

이력에 대한 내역을 추적하는 경우 흐름이 끊기고 직관적이지 못하다는점이 있다

 

직관적인 이력에 대한 개선은 아마도 다음과 같을 것이다

 

 

바로 이런경우에 rebase 를 사용하는 것인데, 문자그대로 재설정 이라는 뜻이다

 

rebase는 별게 없고 merge와 마찬가지로, 한 브랜치의 내용을 다른 브랜치로 병합하는 기능일 뿐이지만,

 

다른점은 rebase는 병합하는 브랜치의 커밋 기록을 변경하기 때문에

 

병합 후에는 두 브랜치의 커밋 기록이 동일해진다

 

그래서 위 그림과 같이 커밋 기록을 단순화하기 위해 사용할 수 있는 병합 방법이다

 

git rebase를 사용했다면 다음과 같을 것이다

 

 

git merge 실습하기)

 

git merge 실습을 위해서 일일이 구성물을 만드는게 번거로운 작업이 될 수 있다.

 

따라서 실습을 위해서 git 환경을 터미널로 빠르게 구성해보고 학습하기로 한다.

 

지금 이 글을 작성하는 개발환경은 `MacOS Ventura 13.3.1` 에서 `git version 2.39.0` 으로 수행하였다. (2023.10)

 

다음의 git merge step1 ~ step6 까지를 드래그하여 터미널에 복사-붙여넣기 하여 실습을 위한 환경을 구축할 수 있다

 

step을 나눈 이유는 몽땅 드래그해서 붙여넣으면 터미널에서 명령어 실행 속도에 따라서 브랜치 순서가 꼬일 수 있기 때문이다

 

step.01) merge 저장소 생성후 main에서 첫 커밋

# merge 라는 디렉토리를 생성하고 이동한다
mkdir merge && cd merge

# git 초기화 하며, 최초 브랜치는 main으로 설정한다
git init --initial-branch=main

# MAIN.md 라는 파일을 한개 만든다
touch MAIN.md

# 생성된 MAIN.md 파일을 `add` 명령어로 스테이징 영역에 추가하여 관리대상으로 등록시킨다
git add MAIN.md

# 변경 작업을 git 저장소에 기록한다
git commit -m "initialize commit"

 

step.02) develop 브랜치 만들고 커밋

# develop 브랜치 생성한다
git checkout -b develop

# develop.txt 파일 생성 후 커밋
touch develop.txt
git add develop.txt
git commit -m "created develop branch"

 

step.03) develop => feature 브랜치 만들고 커밋

# feature 브랜치 생성
git checkout -b feature

# feature.txt 파일 생성하고 커밋
touch feature.txt
git add feature.txt
git commit -m "created feature branch"

 

step.04) develop => hotfix 브랜치 만들고 버그수정 작업을 하여 커밋

# develop 브랜치로 이동
git checkout develop

# develop 브랜치를 가지고 hotfix 브랜치를 생성한다
git checkout -b hotfix

# hotfix.txt 파일 생성 후 커밋
touch hotfix.txt
git add hotfix.txt
git commit -m "created hotfix branch"

# hotfix.txt 파일에 "bug fix"라는 텍스틑 입력한 작업을 수행한다 (실제 무언가의 작업을 했다는 이력을 나기기 위함)
echo "bug fix" >> hotfix.txt

# 작업된 hotfix.txt 파일을 커밋한다
git add hotfix.txt
git commit -m "bug fix"

 

step.05) develop => refactor 브랜치를 만들고 리팩토링 작업을 하여 커밋

# develop 브랜치로 이동
git checkout develop

# devleop 브랜치를 참조한 refactor 브랜치 생성
git checkout -b refactor

# refactor.txt 생성 후 커밋
touch refactor.txt
git add refactor.txt
git commit -m "refactoring work"

 

step.06) 여기까지 수행하고 이제 feature 브랜치로 돌아간다

git checkout feature

 

현재 merge 저장소의 전체 브랜치 상황은 다음과 같다

step.01) main 브랜치를 먼저 생성했으며

step.02) main 브랜치를 참조하여 develop 브랜치를 생성했다.

step.03 ~ step.05) 이후 develop 브랜치를 참조한 feature, hotfix, refactor 브랜치를 생성했다.

step.06) 이동된 feature 브랜치에서 그래프로 보면 아래와 같이 표시된다

 

(좌: vs code에 내장된 git graph의 모습 / 우: vs code 확장프로그램으로 Git Graph를 설치하여 보았을때 모습)

 

feature branch)

 

feature 브랜치의 디렉토리를 살펴보자

다음과 같이 feature.txt 파일이 보이고, 이외에 MAIN.md, develop.txt 도 보이게 된다

 

그 이유는 최초에 main => develop => feature 순으로 브랜치를 생성했기 때문에 해당 브랜치에서의 파일이 보이게 된다

 

우리는 step.03 ~ step.05 를 거치면서 이미 작업을 완료했고(작업에 대한 커밋은 `브랜치명.txt`로 그 기록을 남겨놓았다)

 

이제부터는 merge를 사용하여 작업물을 최종 develop으로 모두 합쳐보도록 하자

 

feature 에서 hotfix 합치기)

 

 

step.06 에 의해서 현재 브랜치는 feature 브랜치일 것이다

 

헷갈리는 경우 `git status`명령어를 사용하면 현재 브랜치 위치가 표시되니 참고바란다

 

git merge hotfix

 

위 명령어로 `featrue` 에서 `hotfix`를 합친다

 

그 결과는 다음과 같다

hotfix.txt 의 내용이 병합되었다

 

그래프 모양이 아래와 같이 변경되면서 "Merge branch 'hotfix; into feature" 라는 커밋이 생성될 것이다

 

vscode 기본 내장 그래프의 모습은 아래와 같다

vscode commit graph

 

Git Graph 확장 설치 된 경우의 그래프는 다음과 같다

vscode extension for "Git Graph"

 

마찬가지로 refactor 브랜치도 feature에 취합해 보자

 

feature 에서 refactor 합치기)

git merge refactor

 

refactor.txt 도 잘 보인다

 

refactor 브랜치에 대한 내용이 병합되면 위와 같이 refactor.txt의 내용도 보이게 될 것이다

 

 

이렇게 feature 브랜치에 hotfix와 refactor 병합작업이 끝났고,

마지막으로 develop 브랜치에 feature 브랜치를 병합하면 된다

 

develop 브랜치에 feature 브랜치 병합하기)

브랜치를 develop으로 변경하고 feature를 병합해주기만 하면 된다

git checkout develop
git merge feature

 

이렇게 해서 develop에서 여태까지의 모든 작업이 다 보이게 된다

 

그래프로 보면

 

이렇게 git merge에 대한 설명이 끝났다

 

merge의 개념은 특별히 헷갈릴것이 없다

 

merge의 장점중의 하나는 병합 대상 브랜치의 변경사항을 순수하게 유지할 수 있다는 장점이 있다

 

그렇기 때문에 병합 후에도 두 브랜치의 커밋 기록은 나뉘어서 유지된다