티스토리 뷰
Sourcetree
안녕하세요!
이번 포스팅에서는 간단하게, git을 GUI 환경에서 사용할 수 있게 해주는 Sourcetree(소스트리)로 rebase와 merge하는 법을 알아보겠습니다.
개인 프로젝트를 할 때나 교육을 받고 있을 때에는 터미널에서 git을 사용했었는데요.
몇 안되는 브랜치를 관리하는 데 있어서는 터미널로 작업하는 것이 공부도 많이 되고 뭔가 더 있어보이고 좋지만, 실제 실무에서는 목적에 따라, 또 하나의 프로젝트에서 개발하는 인원이 많음에 따라 다수의 브랜치를 관리해야 하기 때문에 터미널로 작업하는 것은 부담도 되고, 실수할 여지가 있습니다.
그래서 저도 많은 분들이 애용하시고, 또 지금 팀에서 활용하고 있는 Sourcetree로 넘어와서 조금씩 익숙해지고 있는 중입니다.
Sourcetree의 강력한 장점 중 하나는 아주 많은 브랜치들을 그래프로 보면서 손쉽게 관리할 수 있다는 것인데요!
기능을 개발하면서 rebase와 merge를 적절히 사용하면 깔끔한 브랜치 전략을 가져갈 수 있습니다.
(실제로 저희 팀에서 가져가고 있는 브랜치 전략입니다.)
한번 새로운 테스트 저장소를 만들어서 git rebase와 merge 하는 방법을 알아보겠습니다.
터미널로 하는 것보다 확실히 훨씬 쉽습니다!
관리할 브랜치는 아주 많다!
테스트 저장소 만들기
먼저 테스트 해볼 환경을 간단하게 만들어 보겠습니다.
sourcetree-test라는 이름으로 디렉토리를 만들고, git init 명령어로 git 저장소 초기화를 했습니다. master 브랜치가 생겼네요.
그리고 이이서 text.txt를 만들고 커밋을 차례대로 3개 정도 찍은 후, sourcetree로 해당 저장소를 열어보겠습니다.
신성한 master에 감히 세 개의 커밋을 찍었습니다. 이럴 때 아니면 언제 찍어봐
이제 이 마지막 3번 커밋을 기점으로 새로운 피쳐(feature) 기능 브랜치를 따서 작업을 해야한다고 가정해 봅시다.
그리고 다른 팀원 분도 또 다른 피쳐 브랜치를 따서 작업을 진행한다고 가정해 보겠습니다.
조금 더 진행해 볼까요?
냅다 합치면 안됩니까?
팀원 분은 feature/1 브랜치를 따서 작업하고, 저는 feature/2 브랜치에서 작업하였습니다.
각각 2개의 커밋을 진행했네요.
이 때 팀원 분의 기능 개발이 끝나 feature/1 브랜치를 master 브랜치에 병합(merge)하였습니다. 다음과 같이 말이죠.
feature/1의 브랜치가 master 브랜치로 merge되어 있는 것을 볼 수 있습니다.
앗, 저도 기능 개발이 끝난 참이었는데, 한 발 늦었습니다. 저도 그냥 냅다 master에 합쳐버릴까요?
합칠 수는 있겠죠. 하지만 그렇게 된다면 master 브랜치를 기준으로 세 갈래 길이 생겨버립니다.
3번 커밋에서 출발한 두 기능 브랜치는 master에 잘 합쳐졌지만, 그래프는 조금 복잡해졌습니다.
근데 지금이야 봐줄만해도, 동시간대에 개발하는 기능이 정말 많다면 어떻게 될까요?
그리고 각자 개발이 끝나서 원래 브랜치에 합쳐지는 시점도 다 제각각일텐데, 그럼 그래프는 또 어떻게 될까요?
현재는 master 하나지만, 실제 주요한 개발 흐름을 담당하는 develop 브랜치, QA를 위한 QA 브랜치, 버그 픽스를 위한 hotfix 브랜치... 등등 팀 상황에 따라 관리해야 할 브랜치들이 여러 개라면 또 어떻게 될까요?
그래프는... 안녕.
효과적인 브랜치 2줄 전략
git rebase
git rebase는 이름에서 느껴지다시피 현재 checkout된 브랜치에서 자신의 부모 커밋(베이스)를 변경하고자 할 때 사용합니다.
그래프에서 말하자면, 특정 브랜치 가지를 똑 떼서 다른 커밋에 붙이는 작업이라 볼 수 있겠는데요.
방법은 아주 간단합니다.
3번 커밋에서 분기되었던 feature/2 브랜치를 rebase해서 현재의 master 최신 머지 커밋에 붙여보겠습니다.
먼저 rebase를 할 대상 브랜치로 체크아웃을 합니다. 위와 같이 해당 브랜치의 최신 커밋을 더블클릭하면 바로 체크아웃 할 수 있습니다.
(흰 점으로 표시된 커밋이 현재 상태임을 의미합니다.)
그리고 해당 브랜치를 떼서 붙이고 싶은 부모 커밋에 우클릭-재배치를 선택합니다. 그리고 확인 버튼을 누르면!
위와 같이 feature/2 브랜치가 master의 최신 커밋을 부모로 해서 잘 올라갔음을 확인할 수 있습니다.
git merge
이제 부모를 변경했으니 예쁘게 합치기만 하면 됩니다.
master에 병합할 것이니 master의 최신 커밋으로 위와 같이 체크아웃을 하겠습니다.
그리고 메뉴의 병합을 선택하고, 합칠 피쳐 브랜치의 최신 커밋을 선택한 후, 확인을 누르면 merge가 되는 것을 볼 수 있습니다.
이 때 빠른 병합이 가능해도 새 커밋 생성을 체크해 주세요.
이 옵션이 없으면 새로운 merge 커밋이 생기지 않아서, 피쳐 브랜치를 따서 작업한 게 아니라 그냥 master에서 바로 작업한 것처럼 커밋이 올라갑니다.
이제 merge를 하면!
요렇게 rebase에 이어 merge가 잘 되었음을 알 수 있습니다.
그리고 그래프에서 느껴지다시피 master 브랜치를 기준으로 피쳐가 하나씩 하나씩 분기되고 합쳐져서 깔끔한 2줄을 유지하고 있다는 것을 알 수 있습니다.
브랜치가 많아져도 이렇게 관리하면 관리 포인트를 훨씬 줄일 수 있습니다.
마무리
중요한 것은 rebase는 새로 발생한 피쳐 브랜치에, merge는 기존의 중심 브랜치에 체크아웃 한 상태에서 진행해야 한다는 점입니다.
(이미 터미널로 통달하신 분들은 아주 당연한 얘기겠지만...)
순간 착각하면 헷갈릴 수 있는 지점일 것 같네요.
rebase, merge 각각의 행위 주체가 누구일지 곰곰히 생각해보면 이해하기 어렵지 않으실겁니다.
그럼 이번 포스팅은 여기서 마무리하겠습니다! 즐거운 개발 하세요 :)