728x90

다룰 내용

switch, rebase, merge

 

switch

branch를 switch하는 역할을 한다.

# 다른 방법
git checkout -b [변경 할 브랜치명]

# switch
git switch -c [변경 할 브랜치명]

 

rebase

이름 그대로 re-base하는 "베이스를 재설정 하는 작업"을 의미한다.
(서아라는 블로그에 잘 정리가 되어있어서 링크를 첨부한다)

예를 들어,
main이라는 base가 되는 브랜치에서 협업하고 있다면
한 브랜치의 base를 다른 브랜치의 최신 커밋으로 브랜치의 base를 옮기는 작업이다.

merge, rebase 작업 예시

# b 브랜치를 a로 merge 할때 (current branch -> main)
git switch a
git merge b

# b 브랜치를 a로 rebase 할때
git switch b
git rebase a

# b 브랜치를 a로 rebase 후 merge
git switch b
git rebase a

git switch a
git merge b


rebase에 대해서 더 얘기해보자.

협업을 하다보면 작업 도중에
동료 개발자들이 올린 commit들을
내가 진행중인 사항에 반영해야 될 경우가 많다.

이때 rebase를 사용하면
즉각 반영할수가 있다.

이러한 행위를 rebase없이
merge로 진행한다면 commit 히스토리가 모두 남아
복잡한 히스토리를 갖게된다.

rebase를 사용한다면
base를 옮김(혹은 재정의 라고 생각함)으로써
아주 깔끔하고 직관적인 history로 프로젝트를 관리할 수 있게된다.


검증

말로만 하면 너무나도 이해가 안되어
테스트 프로젝트를 만들어 한단계씩 밟아보았다.
(예제의 기준 branch는 main)

 git switch -c feature/a
 echo "blah blah" >> aa.js
 git add .
 git commit -m 'feature: aa 파일 추가'

 

git switch main
git switch -c feature/b

echo 'blah blah' >> b.js
git add -A
git commit -m 'feature: b.js 파일 추가'

여기까지.
A,B라는 두명의 개발자가 각각
feature/a, feature/b 브랜치에서
각 기능들을 개발하고 있다고 가정한다.

이제 A개발자는 해당 기능의 개발자는
개발을 마쳐 push하고 c라는 기능을 개발하러 갈것이다.
그런데 B라는 개발자는 A가 개발한 a라는 기능을 가져와
개발을 이어가고 싶은 상황이다.

rebase를 이용해 브랜치를 깔끔하게 유지하면서
문제를 해결해나가보자.

git switch main

git switch feature/a
git push origin feature/a

git switch main
git switch -c feature/c

echo "blah blah" >> c.js
git add .
git commit -m 'feature: c 기능 작업시작'

 

git switch main
git switch feature/a
git rebase feature/b

git switch feature/b
git merge feature/a



뭐가 좋아진건지 여기까지 보면 티가 안난다.
작업을 계속 진행해보자.

git push origin feature/b

echo 'blah blah' >> main.js
git add .
git commit -m 'feature: main 서비스 작업완료'
git push origin feature/b


개발자들이 위 처럼 개발을 진행하고 있을때
플젝 관리자가 중간에 PR(Pull Request)을 확인하고
먼저 검토가 완료된 feature/a를 merge한다.

git switch main
git merge origin/feature/a

 

feature/b도 확인이 완료되어 merge한다.

git merge origin/feature/b

feature/c 작업이 완료되어
A개발자는 feature/c를 push한다.

git switch feature/c
echo "mapmap" >> map.js

git add .
git commit -m 'feature: map 기능 작업완료'
git push origin feature/c


관리자가 feature/c PR을 검토 후
merge한다.

git switch main
git merge origin/feature/c



(여기부터 결과 비교가능!!)

git push

자, 결과를 보면
브랜치가 굉장히 깔끔하게 정돈된것을 볼수있다

a -> b로 병합하고
b -> main으로 병합하는 등
여러 과정이 있었음에도

마치 하나의 branch만 추가해 작업한듯이
깔끔한 커밋 히스토리가 완성되었다.
결과 확인하기


같은 과정을 rebase없이 했다면

위와 같은 결과를 받아 볼수있다: 링크

비슷해 보인다면

비교해 볼 포인트는 main 브랜치이다!


rebase없이 작업했을때는 안했을때와 달리
feature:b.js, feature:main서비스 등이
main 브랜치에 히스토리로 남고있다.

그 히스토리가 main으로 관리되지 않고
서브 브랜치로 관리되어,
main브랜치를 상대적으로
깔끔하게 관리할수있음을 확인할 수 있다

728x90
반응형

'개발, 코딩' 카테고리의 다른 글

git 기본기_백과사전(2)  (0) 2022.10.26
git 기본기_백과사전 (1)  (0) 2022.10.24
Webpack 구성 이해하기  (0) 2022.10.04
Rest API 정리  (0) 2022.09.29
java zulu jdk11 설치  (0) 2022.07.31