작년부터 꽤 오랫동안 진행하던 안드로이드 사이드 프로젝트(이하 블루밍)를 프론트와 백으로 나누어 갈아엎는 작업을 시작했다. 말 그대로 갈아엎는 작업이었다. 백엔드는 서버단에 필요한 로직을 모두 새로 짜야했기 때문에 그야말로 대공사 시작이었고… 그렇게 고생길이 시작되었다..
그치만 이 프로젝트 덕분에 포폴에 작성해 내밀 수 있는 프로젝트가 하나라도 생겼다.. 성장에 많은 도움을 주신 제이미님께 무한한 감사의 인사를 드리며,,
현재 블루밍 백엔드는 깃 브랜치 전략으로 git-flow 브랜칭 정책을 사용하고 있다. 아주 기본적인 브랜칭 전략이지만 이마저도 잘 지켜진 프로젝트가 드물었던 것 같다…
git-flow 브랜칭 전략에 대해 간단히 짚고 넘어가보자.

깃을 한번이라도 써본 개발자라면 많이 봤을 git-flow 브랜치 전략 그림이다.
우선 브랜치는 보통 이렇게 5가지로 나뉜다.
깃 레파지토리를 생성하면 master 브랜치가 기본으로 존재하고, 거기에 develop 브랜치를 하나 더 생성하게 될 것이다. 그리고 앞으로 새로 구현하는 기능들은 모두 이 develop 브랜치에서 파생된 feature/{#issue} 브랜치에서 개발하게 될 것이다.
현재 작업중인 feature 브랜치에 현재까지 완료된 작업내역이 모두 반영된 develop 브랜치의 내용이 모두 포함되어야 merge 할 때 충돌이 일어나지 않을 것이라 판단해 새롭게 업데이트 된 내용이 있으면 현재 내 로컬의 develop 브랜치를 update project 해준 다음 현재 작업중인 브랜치에 머지를 해 브랜치 최신화를 해주었다. 여기서 문제가 생겼다…
예를 들어 내가 33번 이슈를 feature/33 브랜치에서 작업중이었다고 하자. 그러면 내가 작업해서 커밋한 내용만 해당 브랜치의 커밋내역으로 올라가야한다. 그러나 develop 브랜치를 merge 하면서 feature/33 에 포함되어 있지 않은 커밋내역이 신규 커밋으로 올라가버린 것이다..

그로 인해 난리난 커밋내역… pr 하나에 커밋이 150개가 넘어가는 진기명기....
이 33번 브랜치는 골 조회 기능에 대한 커밋만 올라가야하는데 기존에 커밋했던 모든 내역이 올라간 것을 볼 수 있다.. 이에 커밋내역을 수정하는 작업을 진행했다.
feature/tmp/{#issue} 이름의 브랜치를 새로 만들어 push 한 후 로컬에서 삭제한다.(로컬에서 현재 진행중이던 작업내역을 원격 저장소에 push 하지 않고 checkout을 해버리면 기존 작업 내역이 다 날아갈 위험이 있기 때문에 우선 임시로 원격저장소에 저장한 후 브랜치 이동 작업을 한다.)develop 브랜치를 update project 해 지금까지 작업했던 내역을 모두 가져온다. 이 때 rebase로 update project 한다.
여기서 로컬의 develop 브랜치로 checkout 한 후에


update project를 rebase로 진행한다.
develop 브랜치에서 새로운 feature/{#issue} 브랜치를 파고 feature/tmp/{#issue} 에 올렸던 커밋내역 중 가져올 커밋들만 cherrypick으로 가져온다.보통 체리픽은 충돌 없이 잘 머지되는 편이나 나는 충돌이 나서 어쩔 수 없이 수동으로 머지를 다 해주었다… 멍청하면 이렇게 뒷수습이 어려우니 브랜치 잘 파자…

feature/{#issue} 브랜치를 지우고 로컬의 feature/{#issue} 브랜치를 새로 push 해 원격저장소에 올린다.
지금껏 프로젝트를 하면서 깃을 사용하기 했으나 이렇게 체계적으로 브랜치 정책과 컨벤션을 정해 사용하진 않아서 아직도 브랜치 다루는 것이 다소 서툰 것 같다. 체리픽도 어떤 경우에 사용해야하는건지 잘 몰라 거의 사용하지 않았었는데 이번 기회에 제대로 다뤄볼 수 있었던 것 같다.