Github

브랜치모델

코드 저장소를 효율적으로 관리하기 위한 워크 플로우

git-flow, github-flow, branch-per-issue

1. git-flow: 5가지 브랜치를 이용해 저장소를 운영하는 브랜치 모델.

    항시 유지되는 메인 브랜치

   소스코드가 병합되면 사라지는 보조 브랜치

1. 메인브랜치: master, develop
2. 보조브랜치: feature, release, hotfix

• master: 라이브 서버에 제품으로 출시되는 브랜치.

• develop: 다음 출시 버전을 대비해 개발하는 브랜치

• feature: 기능 개발 브랜치. develop 브랜치에 들어감.

• release: 다음 버전 출시를 준비. develop브랜치를 release브랜치로 옮긴 후 QA, 테스트를 진행 후 maser로 합친다.

• hotfix: master에서 발생한 버그를 수정하는 브랜치.

git-flow도 관리할 수 있지만, 릴리즈 주기가 짧고 서비스를 지속적으로 테스트하고 배포하는 조직은 github-flow 모델 사용. (더 간단)

2. github-flow:

main브랜치의 역할만 잘 관리하는 방식.

hotfix, feature 브랜치 구분 X.

새 기능 추가 또는 이슈해결 시 작업 브랜치를 생성해 관리하고 작업이 끝나면 소스코드의 병합은 pull request기능 사용.

github-flow 사용법

1. main 브랜치는 어느 시점이든 SW 배포가 가능해야 한다.
   1. 소스코드가 분산되어 보관되는 경우, 모든 소스 코드를 main에서 관리.
   2. main은 항상 최신. 소스 코드 병합 전 충분한 테스트
   3. 테스트는 브랜치를 최신으로 병합하고 릴리즈 관리도구(Jenkins, Travis, Cl 등)을 통해 테스트
2. 기능 추가나 이슈 해결 위해 수정할 때 브랜치 생성은 main에서 만든다.
   1. 기능추가 또는 버그 해결 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지 작성.
   2. 커밋 메시지는 여러 사람과 같이 개발할 때 코드리뷰에 도움이 됨. 표준 정의하고 준수.
3. 개발자는 작업 중 원격 저장소 브랜치로 자주 병합해야 함.
   1. 항상 원격 저장소에 자신이 하는 작업을 반영해 다른 사람들도 확인할 수 있도록 함.
   2. 작업 부분 문제가 발생해서 없어져도 원격 저장소에 있는 소스를 받아서 작업할 수 있도록 관리해야 함.
4. 피드백, 도움 필요 시 풀리퀘스트(pull reauest) 생성
   1. pull request: SW의 형상관리를 책임지는 책임자에게 소스 코드의 병합을 위해 리뷰를 요청하는 행동.
   2. pull request 를 이용해 자신의 코드를 공유하고 리뷰를 요청한 후 검토 사항에 따라 발견한 리뷰 내용을 수정한다.
   3. 병합 준비 완료 시. main으로의 반영을 요구.
5. 소스 코드의 기능에 대한 리뷰가 끝나면 main으로 병합.
   1. 병합을 하면 바로 릴리즈로 반영 될 기능이니까 충분한 논의 후 반영.
   2. main에 병합이 완료되면 작업한 브랜치 삭제.
6. 소스 코드가 mainq으로 병합 후 적용되면 SW의 새 릴리즈가 즉시 배포.

커밋 메시지 작성

커밋 메시지는 제목, 본문, 꼬리말 세가지 부분으로 나눔.

각 부분은 빈 줄을 두어 구분.

• type: 어떤 의도의 커밋인지.
• subject: 영문인 경우 동사를 앞에 둠. 첫 글자는 대문자
• body: 긴 설명 필요한 경우 작성. 무엇을 왜 했는지 75자 이내.
• footer: issue tracker ID를 명시하고 싶은 경우 작성.

출처: https://www.oss.kr/