내가 알던 Git이 아닌가?

Git을 사용하다보니 기존에 무심코 사용했던 방식과 다른 방식으로 Git을 사용하게 되었다. rebase라는 개념을 알게 되었고, 정리가 필요하다고 생각하게 되었다.

rebase?

부트캠프에서도, 실제 현업에서도 Git을 빼고 일할 수 없을 것 같다.
Git을 사용하다보면 브랜치를 어떻게 사용할 지 브랜치 전략에 대해서도 고민하게 된다.
부캠에서도, 현업에서도, main-release-develop-feature와 같이 큰 틀은 변하지 않는 것 같다.

조금 단순하게 main-feature만 사용한다고 가정할 때, 위와 같은 형태로 Git graph가 생성될 것이다.

이 때, main 브랜치에 커밋이 하나 더 생성되면 위와 같은 그래프가 된다.

# feature branch에서
git rebase main

rebase 명령어를 사용하면

feature 브랜치의 base가 되는 커밋이 변경된다.

언제 사용할까?

rebase에 대해 찾아보면 커밋 히스토리를 잘 관리하기 위해서 사용한다고 한다.

딱! 이 때만 사용한다고 할 순 없지만 현재까지 rebase를 사용한 경험을 기록하고자 한다.

원격에서 브랜치를 가져올 때

원격 저장소에서 로컬 저장소로 브랜치를 업데이트 할 때 다양한 방식을 사용한다.

git pull origin develop

항상 pull로 로컬 저장소를 업데이트 하는 편이었는데,
이 때, pull은 fetch와 merge를 동시에 진행하기 때문에
원격 저장소와 로컬 저장소의 브랜치가 다른 경우 merge가 진행된다.

이렇게 진행하다보니 develop 커밋 기록에 불필요한 Merge 커밋이 남기도 하였다.

git pull origin develop --rebase

pull을 할 때, rebase 옵션을 사용하면 가져올 때, merge를 바로 하지 않고 rebase를 진행해 커밋 기록을 정리할 수 있었다.

Merge

혼자 개발 공부를 할 땐, merge를 사용했고,
부캠에서는 squash merge를 사용했다.
현업에 오니 rebase merge...?

아직 알아가는 중이지만, 느낀 그대로 정리하면

1. 기본 merge는 브랜치를 합치는 것, 그대로다.
2. squash merge는 브랜치의 커밋 기록을 merge할 때 하나의 커밋 기록으로 퉁치는 것 같다.
3. rebase merge는 브랜치의 커밋 기록을 그대로 develop에 가져가고자 할 때 사용하는 것 같다.

부캠에서 squash를 사용한 것은 Git을 처음 사용할 때 불필요한 커밋들이 많고 커밋이 정리되지 않은 경우가 많았다. 그래서 하나 하나 커밋을 가져가는 것이 장점이 되지 않았던 것 같다.

rebase를 사용하면서 처음엔 커밋 하나에 잠수함 패치들이 많았는데, 점점 커밋 하나에 어떤 내용을 담아야 하는지 신중해지고 냅다 커밋을 때리지 않게 되었다. 그리고 develop에 문제가 생기더라도 커밋을 찾아내 착착. feature에서 develop에 필요한 것이 생기면 cherry-pick으로 쏘옥.

rebase merge
1. feature 브랜치에서 rebase를 진행한다.
2. develop 브랜치에서 feature 브랜치를 merge한다.

뭔가 rebase를 사용하면서 커밋에 대해 신중해지고, 좀 더 명확한 커밋을 하게 되었다.

사용하다보면 생기는 당황스러움

conflict

rebase 명령어를 사용하면 촤촤촤 자동으로 base를 바꿔주면서 끝났다하면 좋겠지만, 여기도 커밋 간의 충돌이 발생한다.

처음엔 어어 이게 뭐야 하면서 당황하고 reset 했지만, 충돌이 발생하면

1. 충돌을 해결한다.
2. git add . 로 변경 내용을 저장한다.
3. git rebase --continue 로 rebase를 계속 진행한다.

이렇게 문제를 해결할 수 있다.