GitHub Flow

GitHub Flow는 Deploy가 빈번하게 일어나는 프로젝트에 알맞은 브랜치 기반 워크플로우이다.

여기서 deploy란, 소스 코드를 실제 환경에 올려서 실행하는 것을 의미한다.

deploy를 자주 하려면 단순한 개발 과정 및 자동화된 환경이 필요되어지는데 이를 위해 github flow는 적절하다.

 

GitHub Flow 기본 흐름

1. master는 항상 deploy할 수 있는 상태로 둔다.
2. 새로운 작업을 수행할 때는 master 브랜치로부터 새로운 브랜치를 작성; 새로운 브랜치의 이름은 무슨 작업을 할지 알 수 있도록 자세히.
3. 작성한 브랜치를 local repository에 commit
4. 같은 이름의 브랜치를 GitHub remote repository에 만들고 해당 remote repo.에 주기적으로 push
5. 커뮤니케이션(도움, 피드백)이 필요할 땐 pull requests를 주고받음.
6. 다른 개발자가 리뷰 하고 작업 종료를 확인하면 master 브랜치에 통합함.
7. master 브랜치에 통합하면 바로 deploy함

GitHub Flow 규칙

• master 브랜치는 항상 deploy 가능한 상태를 유지해야한다.
• 버그가 생기면 HEAD를 과거로 돌리기만 하면 됨
• 테스트가 없거나 실패한 코드는 절대 master 브랜치에 넣어서는 안됨; CI를 해야함
• 새로운 작업을 할때는 master 브랜치에서 새로운 브랜치를 작성
• 새로운 기능 추가
• 버그 수정
• etc. 모든 작업을 할때 새로운 브랜치를 만들어야함
• ex)
• user-content-cache-key
• submodules-init-task
• redis2-transition
• 다른 개발자가 보더라도 무슨 이름인지 알 수 있도록 짓는 것이 가장 좋음
• 이렇게하면 remote repository의 브랜치 이름을 확인만 해도 팀에서 어떤 작업을 수행하는지 파악이 가능
• 생성한 브랜치에는 작업한다고 명시한 것이외의 것은 절대 하면 안됨
• commit할때는 PR을 리뷰하는 다른 개발자를 고려하여 의도가 명확하도록 commit단위를 주의할 것.(한번에 많은 양을 commit하는 것은 좋지않음.. 조절해서.)
  
• master이외의 브랜치는 부담없이 정기적으로 push할 것.
• master로의 merge후에는 곧바로 deploy하여 코드 정상 실행 확인

GitHub Flow를 위한 전제 조건

• Deploy 작업 자동화
• 지속적으로 deploy를 수행하기에 자동화하여 시간절약
• ex) Capistrano, Mina, Fabric, Cinnamon, Webistrano, Strano, etc. 
• 테스트 
• 테스트 자동화
• 테스트 통과
• 테스트 코드가 없는 코드의 PR을 master 브랜치에 merge하면 안됨.
• Travis CI, Jenkins와 같은 툴을 통해 테스트 통과후 remote repository에 push하도록 할 수 있음
• 테스트 코드 유지보수

GitHub Flow를 위한 추가 사항

• Pull Request의 크기를 작게하자.
• 한번에 많은 양을  PR해버리면 코드 리뷰가 힘들어 진다.
• 테스트 환경 준비
• 테스트 코드가 있다고는 하나 master로 merge 된 것을 바로 deploy하는 것은 위험함.
• 추가적으로 개발 규칙이 필요하다면 Wiki등으로 정리하는 것도 좋은 방법