개발 및 배포 프로세스, 협업 프로세스

Git-flow 기반 배포 프로세스

http://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html

 

Branch 관리

master: 현재 출시된 브랜치

release: 다음 버전의 출시를 위한 QA 브랜치

hotfix/*: 서비스 중인 제품의 긴급 버그 수정을 위한 브랜치(QA없이 바로 수정해야할 때)

develop: 다음 버전 개발을 위한 브랜치. 여기에 신규 feature 개발와 bug fix를 merge한다.

feat/*: 새로운 기능 구현을 위한 브랜치

 

작업 프로세스 예시

https://nvie.com/posts/a-successful-git-branching-model/

 

개발 Process

- 각 팀원들은 develop에서 임의의 feature branch를 따서 개발을 진행한다.

- 개발이 완료된 feature branch를 develop에 PR을 보내어 merge한다.

- 통합된 develop에 유닛 테스트를 진행한다.

- 유닛테스트를 통과하면 develop에서 release branch를 생성한다

- release branch를 staging(test) 서버에 배포한다.

- staging(test)서버에 배포된 제품을 QA한다.

- QA에서 발생한 버그는 release에서 hotfix/* branch를 생성하여 수정하고, 다시 develop에 merge한다.

- QA를 통과한 release branch를 real 서버에 배포한다.

- 배포가 완료되면 해당 release branch를 master와 합친다.

 

 

작업 시 지켜야할 약속

from http://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html

- 작업을 시작하기 전에 이슈 티켓을 생성합니다.

- 하나의 티켓은 되도록 하나의 커밋으로 합니다.

- 커밋 그래프는 최대한 단순하게 가져갑니다.

- 서로 공유하는 브랜치의 커밋 그래프는 함부로 변경하지 않습니다.

- 리뷰어에게 꼭 리뷰를 받습니다.

- 자신의 Pull Request는 스스로 merge 합니다.

 

Commit message: http://karma-runner.github.io/0.10/dev/git-commit-msg.html

{type} : {title}

- body 1

- body 2

 

 

Type 종류

feat (new feature)

fix (bug fix)

docs (changes to documentation)

style (formatting, missing semi colons, etc; no code change)

refactor (refactoring production code)

test (adding missing tests, refactoring tests; no production code change)

chore: 매우 단순하고 사소한 변경사항

 

github 권한과 협업

- Admin: repo에 대한 설정이 가능하지만, 그이외 작업에 대해서는 write와 동일한 권한을 가진다.

- Write: 새로운 branch를 만들어서 PR을 보낸다. review 승인을 할 수 있다. 프로젝트 핵심 멤버의 경우에 적합함.

- Read: fork한 repo에 branch를 만들어서 PR을 보낸다. review 승인을 할 수 없다. 외부 협력의 경우에 적합함.

 

- Review: PR을 보낸 자기 자신은 review를 승인할 수 없다.

- PR: 새로운 branch가 push되면, github에서 자동으로 PR을 만들 것을 제안해준다.

github 권한 설정

github 설정에서 소수의 maintainer에게만 admin 권한을 주고, 공동작업 write를, 그이외에는 read권한만 설정한다.

branches에서 master에대한 보호 규칙을 설정한다.
review가 승인된 경우 정해진 규칙에 따라 merge한다.
 - 방법1: owner가 merge한다.
 - 방법2: assignee가 merge한다.

 - 방법3: 아무나 merge한다.

 

Branch protection rule 설정

 

 

- Require pull request reviews before merging

해당 branch에 대해서는 직접 push할 수 없고, 무조건 branch -> PR을 통해서만 push 가능하다.

 

- Dismiss stale pull request approvals when new commits are pushed

이 옵션을 주면, RP 중인 branch에 새로운 commit이 도착하면 다시 처음부터 review를 진행하도록 강제하는 옵션이다.

 

- Include administrators

Admin도 write와 완전히 동일한 제약을 적용 받는다. 따라서 PR에서 admin priviledge사용도 불가능하고, 직접 push 역시 불가능하다.
만약 admin의 작업을 review할 수 있는 write사용자가 충분하지 않은 경우, 이 옵션은 안쓰는 게 맞고, 그렇지 않으면 admin도 철저히 PR로 작업해야한다.

 

- Restrict who can push to matching branches

write권한을 가진 이용자 중, 해당 branch에 push를 할 수 있는 예외적인 사람을 설정한다.

 

 

 

Coding Convention

프로젝트마다 적절한 코드 컨벤션을 정의해서 리뷰어의 통과를 받아야한다.

https://newsight.tistory.com/292

 

Github 오래된 branch 삭제에 대해

1. 브랜치를 삭제하였을 때, 언제든지 복구 가능한 경우는 오직 PR merged가 완료 되었을 때, 해당 PR issue에 들어가서만 복구가 가능하다.
2. 만약 unmerged branch를 삭제해버리면, 코드 history를 보기가 안되는 등 문제가 발생하므로 주의해야한다.
3. 결국 가장 좋은 방법은 모든 branch를 merge 시킨 후 delete하는 것이다. 그래서 가능하면 unmerged branch를 만들지 않는게 좋다.

Hide merged branches in drop down · Issue #3219 · gogs/gogs