#.6 Github Flow

1) 특징

• 자동화 개념이 탑제되어 편리하다.
• 별도의 브랜치가 다수로 분리되어있지 않다. master 브랜치로부터 모든 브랜치가 나온다.
• 따라서 브랜치 이름을 명확하게 작성할 필요가 있다.
• master 브랜치는 언제나 배포가 가능해야하기 때문에, 언제나 stable 해야한다.
• master로 merge를 진행하기 위해서는 꼭 PR을 통해 리뷰를 받고 merge를 진행한다.

2) 장단점

• 장점
  • branch 구성 전략이 단순하다.
  • 처음 git에 대해 접하는 사람에게는 좋은 시스템이 되어준다.
  • Github사이트에서 제공해주는 기능을 모두 사용해 작업을 진행하게 도와준다.
  • 코드 리뷰를 자연스럽게 사용할 수 있다.
  • CI가 필수적이며 또한 배포를 자동으로 진행할 수 있다.
• 단점
  • CI와 배포 자동화가 되어있지 않은 시스템에서는 사람이 해당 업무를 진행해야 한다.
  • 프로젝트의 규모가 커짐에 따라 점점 관리에 어려움이 발생할 수 있다.

3) Github Flow Tip

(1) master 브런치는 어떤 때든 배포가 가능하다.

master 브런치는 항상 최신의 상태이며, stable 상태로 Product에 배포되는 브런치이다. 그리고 이 브런치에 대해서는 엄격한 role를 주어 사용한다.

(2) 새로운 일을 시작하기 위해 브런치를 master에서 딴다면 이름은 어떤 일을 하는지 명확하게 작성한다.

git flow 와는 다르게 feature 브런치나 develop 브런치가 존재하지 않는다. 그렇기에 새로운 기능을 추가하거나 버그를 해결하기 위한 브런치의 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해주면 좋다.

(3) 원격지 브런치로 수시로 push를 한다.

git flow 와 가장 상반되는 방식이다. 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다.

(4) 피드백이나 도움이 필요할 때, 그리고 머징 준비가 완료되었을 때는 pull request를 생성한다.

pull request 는 코드 리뷰를 도와주는 시스템이다. 그렇기에 이것을 이용하여 자신의 코드를 공유하고, 리뷰를 받을 수 있도록 한다. 물론 머지가 준비 완료되어 master 브런치로 반영을 요구하여도 된다.

(5) 기능에 대한 리뷰와 사인이 끝난 후 master로 머지한다.

곧장 product로 반영이될 기능이기에 이해관계가 연결된 사람들과 충분한 논의 이후 반영하도록 한다.

(6) master로 머지되고 푸시되었을 때는 즉시 배포되어야 한다.

GitHub Flow의 핵심인듯한 master로 머지가 일어나면 hubot을 이용하여 자동으로 배포가 되도록 설정해놓는다.