브랜치와 머지 방법

git-flow

브랜치 전략은 기본적으로 git-flow를 따릅니다.

• master 브랜치는 버전 태깅과 함께 develop 브랜치에서 머지됩니다.
• develop 브랜치는 테스트가 완료된 기능을 feature 브랜치에서 머지합니다.

따라서, feature -> develop -> master 순서(방향)로 머지가 이뤄집니다.

이슈와 브랜칭

khaiii는 저장소의 이름이기도 하면서 동시에 khaiii를 운영하는 팀의 이름이기도 합니다. 팀 멤버의 경우 저장소에 쓰기가 가능하므로 개발(커밋) 시 아래와 같은 절차로 진행하고자 합니다. (팀 멤버로 활동할 분들을 적극 환영합니다.)

• 이슈를 등록하고 담당자(개발하는 사람)를 할당합니다. (예: 이슈 번호 3)
• develop으로부터 feature/3 브랜치를 생성합니다.
• 커밋 로그에는 반드시 이슈 번호를 명시합니다. (예: "이 코드는 내가 봐도 멋진 것 같아. #3")
• feature/3 브랜치에 작업을 마치고 브랜치를 origin에 push 합니다.
• develop <-> feature/3간의 pull request를 만들어 담당자(asignee), 리뷰어를 설정합니다.
• pull request 담당자는 feature/3 브랜치를 모든 리뷰어의 리뷰 후 문제가 없으면 develop 브랜치에 머지합니다.
• pull request 담당자는 feature/3 브랜치를 삭제하고 3번 이슈를 닫습니다.

Pull Request from Fork

멤버가 아닌 분들이 코드에 기여하고자 하는 경우 일반적으로 fork를 통해 수정 및 커밋을 하고 pull request를 요청하게 됩니다. 이렇게 할 경우 프로젝트 멤버가 이슈를 등록하고 feature 브랜치를 활용하는 것과는 다른 프로세스로 진행하게 될텐데요. 다음과 같은 절차로 pull request를 해주시면 감사하겠습니다.

• 가능하면 코드 수정 전에 이슈를 등록하여 khaiii 팀 멤버들과 함께 논의를 먼저 한 뒤 진행하는 것이 좋을 것 같습니다. (권고 사항, 예: 이슈 번호 7)
• 위에 설명한 "이슈와 브랜칭" 절차에서 feature 브랜치를 생성하는 대신, fork한 저장소의 develop 브랜치에 작업을 진행합니다.
• 커밋 로그 작성 시 이슈 번호가 있다면 명시합니다. (권고 사항, 예: "khaiii 팀과 논의했던 이런 기능. #7")