GitHub Flow 이해하기

배포가 정기적으로 이루어진 팀, 프로젝트를 지원한다.

 

평소에 GitHub를 사용할 때 어떻게 흘러가는지에 대해 알 수 있다.

 

1. Create a branch

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

위와 같은 브런치들이 있다.

꼭 지켜야 하는 것은 아니지만

 

협업을 한다면 따르는 것이 좋을 것 같다.

 

프로젝트를 진행하다보면 요구사항들을 받을텐데

가능한 요구사항이 있고 불가능한 요구사항이 있을 것이다.

 

프로젝트에서 브랜치를 새로 생성하면

새 메모장 처럼 여러 코드를 테스트 할 수 있는 환경이 만들어진다.

 

master 브랜치는 항상 배포할 수 있는 환경이 되어야 하니

다른 브랜치에서 작업을 하고 master 브랜치에 머지하는 것이 적절 할 것이다.

 

2. Add commits

여러 명이 협업을 하기 때문에

commit을 할 때

다른 사람이 이해할 수 있도록 커밋(커밋 메시지)이 이루어져야 한다.

https://www.conventionalcommits.org/ko/v1.0.0-beta.4/

Conventional Commits

위 링크는 commit 규칙에 대해 설명해주는 글이다.

위 내용은 따로 포스팅 할 예정이다.

 

commit은 내가 수정, 추가했던 내용마다 별도로 commit을 해줘야 한다.

버그가 발견 됐거나

요구사항이 수정 될 경우 롤백할 수 있어야 하기 때문이다.

별도로 commit을 하게 되면 롤백하기가 수월 할 것이다.

 

 

3. Open a Pull Request

Pull Request를 요청하면

내가 한 commit에 대한 코드 리뷰를 시작한다.

 

GitHub에 올라가 있는 코드와

내가 commit한 코드를 비교하며 보여준다.

 

언제든지 요청 할 수 있고

직접적인 코드에 기여할 수 있는 기회가 생긴다.

 

 

4. Discuss and review your code

Pull Request 요청이 오면

해당 프로젝트 팀 혹은 코드를 관리하는 사람이

commit에 대한 질문이나 수정사항 등의 의견을 올릴 수 있다.

 

관리자는 이 코드를 윈하는 branch에

merge 할 지, close 할 지 결정 할 수 있다.

 

 

5. Deploy

Pull Request 요청을 검토하고

변경 사항들(commit)을 배포하여 production 환경(실 사용 제품)에 배포하여

어떻게 진행되는지 확인 할 수 있다.

 

만약 merge 했던 branch에 문제가 생기면

기존에 master branch를 production 환경에 배포하여 롤백을 할 수 있다.

 

6. Merge

Production 환경에서 검토가 무사히 끝나면

master branch에 병합해야한다.

 

Pull Request로

master branch에 merge되면 코드 변경 히스토리를 저장해야 한다.

 

해당 작업을 검색해서 언제든지 확인할 수 있다.

 

Pull Request 내용 중 특정 키워드(ex, Close #32)를 입력하여

이슈화 코드를 연결할 수 있다.

Close #32를 입력하면 이슈가 닫히게 된다. (언제든지 검색 할 수 있다.)

 

 

출처

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

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

https://guides.github.com/introduction/flow/

Understanding the GitHub flow · GitHub Guides