티스토리 뷰

형상관리

GitHub Flow

DevES 2016. 10. 6. 18:01

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등으로 정리하는 것도 좋은 방법




댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
글 보관함