IT 공부/주절주절 일기 같은 곳

그냥 써보는 git flow 이야기

수박한암살자 2022. 3. 4. 16:59

분명 내가 입사할 땐 svn도 나름 쓰는 곳이 있었는데 이젠 거의 없다고 봐도 무방하다.

요즘은 git flow를 기반으로 교육받는게 어느 회사나 기본적인 역량이 된 듯 하다.

 

팀 단위 프로젝트에서 svn보단 좋아보이는 건 거의 명백하지만

막상 잘 쓰고 있냐고 물어보면 선뜻 대답하기 힘든게 git이다.

 

특히 동시에 많은 유지 보수 작업이 돌아가다보면 브랜치 관리가 엉망이 되고

충돌이 일어나는 경험은 개발자라면 누구나 겪어봤을 것 같다.

 

이건 좀 오바이긴 하지만 절반 수준 정도로는 꼬이는 것까지 직접 보기도 했다

 

따라서 좋은 git branch 관리는 개발자에겐 필히 동반되는 작업이기도 하다.

 

하지만 막상 그 관리 방법에 정답이 없는 것도 느껴진다.

그리하여 그냥 상황에 따른 git 관리 방법이나 개인적인 참고 용도로 남겨보고자 한다.

 

1. 머지 브랜치를 예쁘게 하고 싶다.

- 일단 머지 커밋 자체를 없애면서, 마치 하나의 브랜치에서 작업한 것처럼 보이고 싶을 때 쓰는 방법을 보자.

github을 쓴다면 rebase and merge를 쓰면 깔끔하게 만들 수 있다.

rebase 전
rebase 후 (출처 : https://backlog.com/git-tutorial/kr/)

머지 커밋은 남기면서 작업하고 싶다면 어떤 방법이 좋을까?

방법은 issue3 브랜치 작업 상태에서 'git pull --rebase origin master' 를 실행하면 된다.

 

그 경우, issue3 브랜치가 issue2 이전 커밋에서 분기가 된 것이 아니라

issue2 머지 이후 분기가 된 것처럼 다시 히스토리가 잡히게 된다.

 

이를 이용하면 아래와 같은 느낌의 브랜치를 이어나갈 수 있다.

 

자세한 방법은 https://jusths.tistory.com/60 이 글을 참고하도록 하자.

 

2. 커밋 수 자체를 줄이고 싶다.

- 누구나 한번의 커밋으로 모든 걸 끝내고 싶어하겠지만 작업이란게 뜻대로 되지 않는다.

또한 작업 내용이 많다면 여러번의 커밋을 할 수 밖에 없다.

예를 들어 커밋을 10번을 한 feature 브랜치가 있다고 가정하자.

 

다른 사람이 동시에 작업 중인 것도 없고 그냥 PR 올린 뒤 머지해도 되지만 브랜치 히스토리가 지나치게 길어지는 느낌을 피할 수 없다.

이 경우에는 squash를 쓰면 된다.

 

현재 작업 브랜치에서 git rebase -i <변경하고 싶은 커밋의 직전 커밋 ID> 로 squash가 가능하며

보통 <변경하고 싶은 커밋의 직전 커밋 ID> 부분은 'HEAD~{원하는 개수}' 를 입력하여

현재 커밋에서부터 squash할 개수만큼을 입력한다.

만약 최근 3개의 커밋을 합치고 싶다면 HEAD~3 을 입력하면 된다.

 

자세한 방법은 https://backlog.com/git-tutorial/kr/stepup/stepup7_5.html 이 글을 참고하도록 하자.

 


1, 2번을 합치는 방법도 있다.

 

https://techblog.woowahan.com/2553/

 

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

{{item.name}} 안녕하세요. 우아한형제들 배민프론트개발팀에서 안드로이드 앱 개발을 하고 있는 나동호입니다. 오늘은 저희 안드로이드 파트에서 사용하고 있는 Git 브랜치 전략을 소개하려고 합

techblog.woowahan.com

 

조금 중간에 명령어가 명확하지 않은 것 같긴한데(오늘 따라해봤을 땐 명령어에서 오류가 났다)

참고하면 좋은 글이라 생각한다.

 

짧게 요약하자면 2번 방법으로 커밋 수를 줄이고

1번 방법으로 브랜치의 분기점을 최신화하는 방식이다.


처음 말했다시피 git flow 관리에 정답은 없다 생각한다.

위 방법들에 익숙해지면 좋지만 익숙치 않다면 미친 듯이 꼬여버린 git 히스토리를 목격할 수 있고

만약 원격 저장소에 push라도 되었다면 이를 롤백하는 것은 쉬운 일은 아니다.

 

작업 인원이 많고 동시 진행되는 것도 많다면 조금 타이트하게 git flow 전략을 세워 진행하는 것이 서로에게 좋고

소수의 팀원들이라면 느슨하게 세워 관리하는 것이 큰 스트레스를 받지 않고 작업할 수 있는 길이라 생각한다.

반응형