Github Workflow

Git Branch Strategy

브랜치 관리에 명확한 기준이 없으면 해당 브랜치가 어떠한 목적으로 생성되었는지 알 수 없다

Git 브랜치 전략은 Git 브랜치를 효과적으로 관리하기 위한 워크플로우

Git flow

Gitflow에는 5가지 브랜치가 존재

• master : 제품을 배포하는 브랜치
• develop : 개발자들이 해당 브랜치를 기준으로 각자 작업한 기능들을 병합
• feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 병합
• release : 배포를 위해 master 브랜치로 보내기 전에 먼저 품질검사를 하기위한 브랜치
• hotfix : master 브랜치로 배포를 한 뒤 버그가 생겼을 때 긴급 수정을 위한 브랜치

Git flow 브랜치들의 분기와 병합 예시

Github flow

Git flow 가 Github에서 사용하기에 복잡해서 나온 브랜치 전략

Git flow와 달리 hotfix 브랜치와 feature 브랜치를 구분하지 않는다

수시로 배포가 일어나며, CI와 배포가 자동화 되어있는 프로젝트에 유용

소규모 개발을 할 때 적합

1. master 브랜치는 언제든지 배포 가능 상태 유지
   • merge 하기 전에 충분히 테스트를 해야한다
   • 항상 최신 상태를 유지해야 한다
2. master에서 새로운 일을 시작하기 위해 브랜치를 만든다면 이름을 명확히 작성
3. origin 브랜치에 수시로 push해서 다른 사람들이 확인할 수 있도록 한다
4. master에 병합을 준비할 때 Pull Request를 생성
5. master 브랜치에 병합되고 push까지 완료되면 즉시 배포

Github flow  브랜치들의 분기와 병합 예시

Fork & Pull Request

규모가 있는 개발을 할 경우 fork와 pull request를 더 자주 활용

fork는 브랜치와 비슷하지만 프로젝트를 통째로 외부로 복제해서 개발하는 방식

개발을 해서 Pull requests로 원 프로젝트 관리자에서 머지 요청을 보내면 원 프로젝트 관리자가 Pull requests된 코드를 보고 적절하다 싶으면 그때 그 기능을 붙히는 식으로 개발을 진행

---

Continuous Integration 애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법