[프로젝트] git-flow 협업 방식 변경

https://young1403.tistory.com/55

[프로젝트] Git Flow를 사용해볼까?

 

내가 이제껏 알던 git-flow는 git-flow가 아니었다.

 

윗 글에서 협업 방식을 git-flow 형태로 바꾸어서 좋다는 글을 쓴 적이 있다. master와 develop 이렇게  두개의 브랜치로 개발을 진행하면서 feature브랜치의 필요성을 못 느끼고 개발을 하던중에 아래와 같은 오류사항을 겪었다.

제일 상단 분기를 보면 '남의영'과 'woowang' 에서 브랜치가 나뉘어지면서 merge가 되지않는 상황인 것이다.

Fast-Forward 상황이다.

수정 전 git log(충돌상태)

남의영이라는 'a사용자'와 woowang이라는 'b사용자'가 있다.

1. a사용자 commit

2. b 사용자 commit

3. b 사용자 push

--> b 사용자가 a 사용자를 앞질러간 'Fast Forward'상태

 

이렇게 되면 b사용자가 push하였기 때문에 최신상태가 아닌 a사용자는 push하기 전에 merge를 먼저 진행하여 최신화를 시켜주고 push를 해야한다.

순간순간의 commit push를 통제하기는 힘들다는 생각이 들었고 , 현업에서 일하고있는 개발자분들께 이 상황에 대해 도움을 요청하여 얘기를 하다보니

1. PR을 안올려 코드리뷰가 없는 점
2. feature 브랜치없이 develop에서 바로 commit, push를 하는점

이 두가지를 가장 큰 문제로 지적을 받았다.

 

그래서 우선 다음날 수업시간 이후에 바로 팀 회의시간을 가져서 이 문제를 해결하는 시간을 가졌다.

 

feature branch

• 1. '사람이름'으로 각자 파자는 의견,
• 2. 도메인별로 브랜치를 만들자는의견.
• 3.  issue 별로 만들자는 의견,

의견은 이렇게 크게 3가지로 나뉘었고 아래와 같은 흐름으로 3번째 의견을 채택하게 되었다.

 

첫번째는 '사람이름'으로 파면 브랜치의 명시성이 떨어진다는 단점과 이미 git기록을 보면 github아이디 혹은 닉네임으로 식별이 가능하다는 점에서 배제를 하였다.

 

두번째는 도메인별로 브랜치를 만들자는 의견은 예를들어 , post와 reply가 협업을 하게되면 post_reply 이런형태로 feature를 만드는게 어떤가 였는데 브랜치 이름을 도메인 이름의 조합으로 나타내기엔 이 또한 무슨 작업을 하고있는건지 명시성이 떨어진다는 이유와 feature브랜치는 가능한 잘게 '기능구현 단위'로 나누는게 좋다는 의견에서 였다.

 

세번째는 feature 브랜치를 issue별로 만들자는 의견을 채택을 하였다. 그 이유는 위에서 말한 '기능구현 단위'에  가장 적합했다. 

예를 들어 '내가 post에서 좋아요 기능을 만들고 싶어!' 일때 이 기능을 위한 issue와 브랜치를 만들고 그에대해 PR을 올리면

그걸 리뷰하는 사람 입장에서도 읽고 이해하기가 편하다. 였다. 그래야 코드리뷰도 훨씬 부담스럽지 않게 원활하게 돌아갈거라는 이유에서 만장일치로 채택하게 되었다.

 

PR

 

이어서 PR을 할지말지 의논을 하였어야 했는데 팀원들 모두 이전 git협업방식에서 PR에 대한 불편함을 크게 느낀바들이 있어서 PR올리는 방식을 꺼리는 분위기였다. PR을 안올리고 코드리뷰만 따로 진행하자라는 의견들이 힘을 얻었었다. 하지만 현업자 10명중 10명이 PR은 필수라고 하는 얘기를 듣고 왔기에 배우는 입장인 우리가 그것을 왈가왈부 판단할 레벨은 아니라는 생각이 들었고, PR의 중요성을 강하게 어필하였다. 

우선 우리가 github, gitflow 이 방식들을 변화시키고 여러방식으로 시도해보려는 근본적 이유는 현업에서 하는 일들을 실전처럼 하기위함이고, 현업에선 모든 개발자가 이렇게 PR을 올린다는 사례와 코드리뷰의 편리함, private으로 되어있는 프로젝트이지만 PR을 올리게되면 github commit 반영 등을 예로들어 설득에 성공했다.

 

기존 git commit -> push -> fetch -> pull -> 개발시작 인 방법에서
        develop -> feature -> git commit -> push -> Pull Request 방식으로 바뀌었다.

 

• 3. 여기에 더해 팀장님께서 추가로 알아봐온 git convention(커밋 메시지 컨벤션) 규칙을 정해서 커밋 메시지의 틀을 통일시켰다.    우리 팀에선 아래와 같은 형태로 개발 단위를 나누어 코드리뷰하기가 좀 더 편해지고 git을 들여다 보았을때 '누가 무슨작업을 하였는지'  파악하기가 더 쉬워졌다.

 [Domain] #issue number Messege

수정 후 git log

 

정리

---

• issue별로 나눈 feature 브랜치를 만들어 git flow 협업 진행(feature 브랜치의 중요성인지)
• PR을 통한 코드리뷰 방식 재추가
• 커밋 메시지 컨벤션 규칙 추가