본문 바로가기
IT라이프/Linux

Git merge 에 관한 고민

by zairan 2022. 10. 25.

git 를 사용해서 팀원들과 함께 작업을 하다보면 내 작업 브랜치가 몇주전에 만든 것인데도 불구하고, 그 사이에 다른 팀원들이 수십개의 파일을 먼저 main 브랜치에 머지하는 상황이 있을 수 있다.

 

보통 github 에서 아래와 같은 세 가지 경우로 처리할 수 있는데,

 

1. 첫번째 방법, github 에서 내 작업 브랜치에 대해서 에러나 특이사항은 없으니 그냥 PR을 머지해버리고 끝낸다.

 - 이 방법의 장점은 내 게으름을 인정할 수 있다. 그러나 내 파일이 들어간 후 빌드하는 과정에서 실패하면 hotfix 로 대응해야 하는 경우가 생긴다. 

 

2. 두번째 방법, 내 작업 브랜치에 main(master)를 merge 하고 PR 을 머지한다.

- 나쁘지 않은 방법이다. 단점은 실제 main 에 들어가는 순서가 앞뒤가 바뀌게 된다. 단, 내 작업순서 뒤에 다른 팀원의 작업분이 들어간 채로 main 에 들어가게 된다. 내 작업분량이 나중에 main 에 들어가는 것이 시간적으로는 맞으며, 내 작업분에 문제가 생겼을 때 revert 하게 되면 꽤나 귀찮은 경우가 발생한다. 혹시 내 작업분에 의해서 DB 가 바뀌게 된다면 더욱 주의해야 할 것이다.

% git branch
* feature/A
  main

% git fetch

% git merge main

% git push

 

3. 세번째 방법, 내 작업 브랜치를 rebase 해서 PR 을 머지한다.

- 내 작업 브랜치를 만든 시점을 현재 머지하려는 브랜치의 최신점으로 바꾸는 작업이다.

여기서는 main 으로 머지한다는 내용이다.

% git branch
* feature/A
  main
  
% git fetch

% git rebase main
Successfully rebased and updated refs/heads/feature/A

// 강제 푸시옵션 force -f 이 필요한 경우도 있는 것 같은데 나중에 업데이트
$ git push -f origin feature/A
반응형

댓글