Git Flow와 Commit Message Conventions에 대해서

지현배·2023년 10월 2일

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

Git Flow

신기한 점

처음에는 우형 기술블로그를 볼 때 솔직히 이해가 잘 안됐다. 그냥 5가지의 브랜치 종류가 있다. 어떤 기능을 한다. 이정도만 이해하고 프로젝트를 했었다. 한 프로젝트를 딱 끝내고나서 다시 보니깐 gitflow가 어떻게 구성되어있고, 어떻게 동작하는지 왜 쓰는지 이해가 간다. (돌이켜보면 모든 개발공부를 했었을 때 이와 같은 비슷한 과정을 거쳤었고 거치고있는 중인 것 같다.)

Git-Flow 사용하게 된 이유

기존 배민 앱 개발 프로세스는 '기획 - 디자인 - 개발 - QA - 출시' 순서의 흐름 이였다.
안드로이드 앱 개발자는 2~3명 이였고, 회사가 지속적으로 성장하면서 개발자를 채용하고, 개발기간이 3주 이상 필요한 작업들이 많아지기 시작하면서 개발 프로세스의 변화가 생겼다.

우선순위에 따라 나열된 작업 중 우선순위가 높은 작업부터 하나씩 선택해 작업을 나눠 갖는다. 이번 버전에 포함될 필수 작업과, 다음에 언젠가 배포될 작업들을 병렬로 작업진행한다. 병렬로 처리하던 작업들이 완료 되면, 가까운 배포 주기에 포함시켜 출시한다.

이러한 개발 프로세스를 가장 잘 반영할 수 있는 모델이 Git-Flow라고 생각했고, 개발자들이 Git을 사용하는데 어려움이 없어 도입을 하게 됐다.

+) QA란? (Quality Assurance, 품질 관리)

Git Repository 구성

Repository는 Upstream Remote Repository, Origin Remote Repository, Local Repository 3부분으로 구성된다.

Upstream Remote Repository는 개발자들이 공유하는 저장소로 최신 소스코드가 저장되어있는 원격 "공유" 저장소이다.(develop에 해당하는 것 같다)
Origin Remote Repository는 Upstream Remote Repository를 Fork한 원격 "개인" 저장소이다. (feature에 해당되는 것 같다)
Local Repository는 내 컴퓨터에 저장되어있는 "개인" 저장소이다.

+) 여기서 Remote는 GitHub을 의미하고, Local은 내 컴퓨터를 의미한다.
+) Fork는 develop에서 feature/xxx로 복제하는 과정을 말한다.
Fork한 feature에서는 자유롭게 수정 및 관리가 가능하다. (독립적이기 때문)

이 그림은 Git Repository의 구성과 워크플로우를 설명하고 있다.
Local Repository에서 작업을 한 후(add, commit을 거쳐), Origin Remote Repository(GitHub)에 push한다.
GitHub에서 Origin Remote Repository를 Upstream Remote Repository로 merge(병합)하는 Pull Request(PR)을 생성하고, 코드리뷰를 거친 후 merge한다.
다시 새로운 작업을 할 때는 Local Repository에서 Upstream Repository를 pull한다.(develop에 머지된 최신변경사항을 local에 반영하기 위해서)

Git Work Flow Rules

[팀마다 다를 수 있음, 우형 기술블로그에서 제시한 룰]
1. 작업을 시작하기 전에 Jira 티켓을 생성한다.
2. 하나의 티켓은 되도록 하나의 커밋으로 한다.
3. 커밋 그래프는 최대한 단순하게 가져간다.
4. 서로 공유하는 브랜치의 커밋 그래프는 함부로 변경하지 않는다.
5. 리뷰어에게 꼭 코드리뷰를 받는다.
6. 자신의 Pull Request는 스스로 merge 한다.

이전 프로젝트에서 안드로이드팀의 룰이였다.
🚨Rules🚨

절대로 main, develop branch에서 ‘직접' 수정을 하지 않는다.
앱이 정상적으로 실행되지 않는 브랜치는 push, merge하지 않는다.
PR에 다른 사람들이 approve 하기 전까지 merge를 하지 않는다.
팀원이 담당한 부분을 수정해야 하는 경우 변경사항을 사전에 전달한다.
merge된 브랜치는 삭제한다.

Git-Flow 전략

Git-Flow에는 5가지 브랜치가 존재한다.
항상 유지되는 메인 브랜치들(master, develop)과 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)이 있다.

master : 제품으로 출시될 수 있는 브랜치
develop : 다음 출시 버전을 개발하는 브랜치
feature : 기능을 개발하는 브랜치
release : 이번 출시 버전을 준비하는 브랜치
hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치

develop 브랜치가 사실상 중심이라고 볼 수 있다.
1) 새로운 기능 추가 작업이 있는 경우 develop 브랜치에서 feature 브랜치를 생성해 작업을 하게 된다. 그 작업이 끝나면 feature 브랜치에서 develop 브랜치로 merge한다.
2) develop에서 이번 버전에 기획된 모든 기능들이 merge 되었다면 QA를 하기 위해 develop 브랜치에서 release 브랜치를 생성한다. QA를 진행하면서 발생한 버그들은 release 브랜치에서 수정한다.
3) QA를 무사히 통과했다면 release 브랜치를 master와 develop 브랜치로 merge한다.

마지막으로 출시된 master 브랜치에서 버전 태그를 추가한다.

hotfix는 master 브랜치에서 발생한 버그를 긴급 수정할 때 사용하는 브랜치이다.
버그를 수정하고 release 브랜치와 마찬가지로, develop과 master에 merge한다.

Git-Flow를 이렇게 하고 있어요

이 부분부터는 안해봐서 잘 모르겠다. 다음에 정리해야지
feature브랜치에서 작업브랜치를 생성해서 그걸 다시 feature에 머지한다? 그런건가? 해본적이 없다.

Commit Message Conventions

참고자료
AngularJs commit convention

Commit message 형식

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

어떤 줄도 100자를 넘기지 마라! 다양한 Git tool들에서 읽기 쉽도록 하기 위함!

먼저 예시를 하나 보고가자

fix($compile): couple of unit tests for IE9

Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.

Closes #392
Breaks foo.bar api, foo.baz should be used instead

Commit Message - subject line

변경 사항에 대해서 간단한 설명이 포함되어 있다

type
어떠한 의도로 커밋을 했는지 작성한다

feat (기능 구현)
fix (버그 수정)
docs (문서 작업 / README.md 등)
style (코드 스타일, 세미콜론 누락 등 / 코드의 로직에 영향을 주지 않아야 한다.)
refactor (코드 리팩토링)
test (테스트 코드)
chore (프로그램 실행과 관련 없는 작업, 빌드 시스템, 패키지 매니저 설정 등)

scope
어떤 범주의 코드를 수정했는지 적는다
$location, $browser, $compile, $rootScope, ngHref, ngClick, ngView 등등등...

subject

명령형, 현재 시제 사용 : change(o), changed(x), changes(x)
첫글자는 대문자를 사용하지 않는다
마지막에 .을 붙이지 않는다

Commit Message - body line

명령형, 현재 시제 사용 : change(o), changed(x), changes(x)
Commit해서 이전과 변경된 사항들을 작성한다.

Commit Message - footer line

Breaking changes (주요 변경사항)
주요 변경사항은 footer에 그 변경사항에 대한 설명, 이유, 이전버전에서 현재 버전으로 코드를 어떻게 바꿀 것인지에 대한 것들을 작성한다.

Referencing issues (이슈 참조)
이슈를 해결하고 닫을려면 분리된 줄에 Close 키워드를 작성하면된다.

[예시]
Closes #234
Closes #123, #245, #992

commit message 예시, 더 많은 예시는 AngularJS링크로 들어가서 확인하자

feat(directive): ng:disabled, ng:checked, ng:multiple, ng:readonly, ng:selected

New directives for proper binding these attributes in older browsers (IE).
Added coresponding description, live examples and e2e tests.

Closes #351

feat($browser): onUrlChange event (popstate/hashchange/polling)

Added new event to $browser:
- forward popstate event if available
- forward hashchange event if popstate not available
- do polling when neither popstate nor hashchange available

Breaks $browser.onHashChange, which was removed (use onUrlChange instead)

지현배

Maker

이전 포스트