Git (1). main branch의 설정을 각 개발자의 feature branch에 적용

보통 Git을 통해 Merge를 한다면 

main이나 develop 브랜치와 같은 곳에 개발자의 branch를 merge하고

여기에 사용되는 세 가지 방식이 3-way, fast-forward, rebase merge이다.

 

여태까지 나는 작은 branch를 큰 줄기인 main, dev branch에 병합하는 방식만을 생각했다.

 

문제 상황) main, dev에서 Setting을 바꿔서 각 feature 에 update가 필요한 상황.

 

찾아보니 ESLint, Prettier, Babel, Webpack 설정 등

main과 develop branch에서 공통 환경 설정을 변경 한 뒤

각각의 feature branch에 업데이트를 해줘야하는 상황이 종종 발생하는 듯 하다.

 

1) Dependency(의존성) 문제

현재 내가 진행하고 있는 프로젝트에서도 동일한 상황이 발생했다.

package.json의 의존성이 각기 다른 부분도 있었다.

또한, 설치의 순서가 다르면 package-lock.json의 의존성 트리가 다르다.

(따라서 각기 다른 순서로 모듈, 라이브러리 설치를 진행했다면 의존성 트리가 달라지기에 이것의 통일이 필요하다.)

 

즉, package.json 상으로 같은 파일을 보여주더라도

설치의 순서가 달라 의존성 트리, 즉 package-lock.json이 달라지고

모든 라이브러리, 프레임워크, 모듈의 버전이 동일하지 않게 설치되는 상황이 발생한다.

즉, 의존성 트리에 따라서 다른 사람의 코드가 현재 내 코드에서 실행이 안되는 경우가 생기는 것이다.

 

참고로, 배포자의 package-lock.json, package.json 두 개의 파일을 받아서

npm install을 진행한다면, 배포자의 설치 순서와 동일하게 설치가 되도록 npm이 작동된다.

 

 

2) Rebase의 재발견

rebase란, 단어 그대로 base를 재설정하는 것이다.

배울때는 항상 rebase든 뭐든 결국 merge의 대상은 develop이나 main, 즉 큰 줄기에 적용해 병합하는 경우만을

생각했지 그 반대의 경우는 생각해본적이 별로 없었다.

 

그림으로 그려보면 아래와 같다.

우리가 흔히 생각하는 rebase와 현재 상태에 알맞게 적용될 rebase의 차이이다.

오른쪽의 그림이 딱 현재 상황에 알맞는 것 같다.

main에 변경이 있었고, 우리는 이 변경사항을 업데이트한 상태에서 개발을 진행한 것 처럼 볼 수 있기 때문이다.

 

그러면 이를 적용하려면 어떻게 해야할까?

1. git checkout main(dev) -> git pull origin main(dev)

먼저 main이나 dev branch와 같이 환경설정이 변경된 branch로 이동한다.

(참고로 아직 프로젝트 초기단계일 경우, main은 있어도 dev branch의 원격 branch가 없었다.)

그리고 git pull을 입력해 프로젝트의 원격 repository로 부터 해당 branch의 최신 스냅샷을 내 로컬 repository의 해당 branch에 가져오는 작업이 필요하다.

 

2. git checkout feature

설정을 update할 branch로 진입한다.

 

3. git rebase main(dev) 

현재 branch에서 main(dev) branch의 HEAD를 base로 하는 rebase 작업을 진행하는 것이다.

여기서 git rebase -i main(dev)와 같이 쓰면 (-i에서 i란 interactive, 대화형을 뜻한다.)

내가 남기거나 없애고 싶은 모든 commit 의 목록이 뜨고,

여기서 이를 선택할 수 있다. 진행할 작업의 목록은 다음과 같다.

 

• pick: 해당 커밋을 그대로 적용
• reword: 커밋 메시지만 수정
• edit: 커밋 내용을 수정
• squash: 이전 커밋과 병합
• fixup: 이전 커밋과 합치면서 커밋 메시지를 무시
• drop: 커밋을 제거

 

4. if) confilct 상황 발생 ➡️ merge 작업 ➡️ 변경 사항 저장 ➡️ 변경 사항 staging: git add ➡️  git rebase --continue

rebase작업을 진행하는 도중 특정 커밋에서 conflict가 날 경우,

이를 merge하기 위한 작업을 필요로 한다.

번거롭지만 이러한 경우는 대부분 설정의 문제에서 발생하기에, 다뤄야 할 부분은 많지 않으리라 생각된다.

 

 

추가적으로, 이러한 경우에는 feature branch에서 git merge origin main(dev) 과 같은 방식으로 해도 된다.

commit을 많이하고 현재 feature의 진행상황이 엄청나게 많다면, 병합 과정에서 충돌이 많이 발생할 수도 있다.

 

 

결론)

git rebase의 다른 시각을 통한 접근으로 git을 이용한 버전관리 전략의 폭이 다채로워진것 같다.

그리고 이런것도 계속해서 사용해봐야 선택의 폭이 넓어지는 것이라 rebase에 대한 개념의 정립과 자신감도 붙은 것 같다.

 

 

https://graphite.dev/guides/git-rebase-main-into-feature

How to rebase main git branch into a feature branch