#004. 백엔드 성장 일기 : source tree

어제 오후 향로가 태그를 하셔서 확인해보니 source tree 이미지와 함께 PR merge를 하기 전에 rebase가 빠져있다는 말씀을 해주셨다.

보통 인프런에서는 지정 리뷰어가 approve를 한 후에 merge를 해주고 있고, 리뷰를 부탁드리기 전에 rebase + push를 하고 있다.

혹시나 내가 rebase를 빠뜨렸나 하는 생각에 source tree를 다시 찾아보는데 rebase를 하면서 메인 브랜치에 맞추는 용도로는 자주 사용해봤어도, 전체적인 흐름에서 본 적이 없다는 것을 알게되었다. 그래서 어떻게 생긴 문제였고 어떻게 확인할 수 있었으며 어떻게 해결할 수 있는 지까지 확인해서 정리해보려고 한다.

 

---

우선 source tree는 코딩에 완전히 집중할 수 있도록 Git 리포지토리와 상호 작용하는 방법을 단순화하는 무료 GUI(그래픽 사용자 인터페이스) 데스크톱 클라이언트다. (구글 검색 첫 글) 쉽게 말해서 깃 레포의 상태를 이미지로 보여주는 툴이다. 사용법은 언젠가 한 번 글 재료가 떨어지면 써보려고 한다.

 

아래는 strykerJS 라는 오픈소스를 source tree로 열어본 결과이다. 가장 안 쪽(빨강)이 main branch가 되고 파랑, 노랑 선이 git checkout -b 브랜치명 을 하면 분기가 나눠지는 새로운 브랜치이다. (잘 찾으면 내 contribute도 있다!)

 

 

 

위 문제의 예시를 잘 관리되고 있는 오픈소스에서 찾기에는 공수가 많이 들 것 같아서 source tree의 브랜치 부분만 설명해보려고 한다.

상황은 왼쪽과 같다.

파란색 메인 브랜치가 있고, 맨 아래 박스에서 노란색 브랜치가 생겼고 merge를 했다. 그리고 이 merge 이후 빨간색 유저가 브랜치를 만들어서 merge를 했다.

노란색 유저 입장에서는 이 (빨간 브랜치가 생성되어 merge 되었다는) 사실을 알지 못하고 rebase 없이 새로운 자신 로컬의 메인 브랜치에서 새로운 브랜치를 다시 생성해서  새로운 PR merge 시킨 상황이다.

 

이 상황을 해결하려면 두 가지 방법이 있다.

(1) PR을 만드는 개발자 입장에서: 항상 새로운 브랜치를 만들기 전에는 메인 브랜치를 가지고 와서 rebase를 할 것

(2) PR merge를 하는 리뷰어 입장에서: merge 전에 rebase 버튼을 확인해서 누르기. 또는 개발자에게 리베이스 하고 오세요 하고 말하기.

 

 

 

 

 

(2)을 조금 더 설명해보자면 왼쪽과 같은 상황이 되었을 때 (충돌이 없다는 가정하에) 깃헙 인터페이스에 이런 것이 생긴다.

말로 설명하자면, 현재 PR이 기존 코드와 부딛히는 건 없는데 , 메인 코드가 바뀌었으니 rebase 할래? 하고 묻는 것이다. 

 

빨간 버튼을 눌러보면 다음과 같이 ---과 그냥 rebase + force push로 내 PR 커밋을 다시 쓰는 방법이 있다. 

 

인프랩 규칙대로라면 update with rebase를 해주면 된다.

 

 

마지막으로 source tree를 보는 방법. 깃 브랜치가 잘 운영된다면 위의 strykerJS 브랜치 같이  main 브랜치와 PR branch 두 줄이 유지 되어야한다. (정확히 말하면 세 줄인데, 저건 레포 운영 정책으로 가져가는 branch가 있는 것 같다.) 그래서 이걸 인지한 상태로 그래프를 쭉 보면서 상태를 쉽게 확인할 수 있다.

 

오늘의 교훈:

(1) 새 PR 만들기 전에는 항상 메인 rebase를 하자.

(2) 깃 브랜치 그래프가 이상하면 혹시 나인가 의심해보고 작성자에 익숙한 이름이 있다면 자수해서 감형받자.

---