GitHub Flow 이해하기
GitHub Flow는 배포가 정기적으로 이루어지는 팀 및 프로젝트를 지원하는 간단한 브랜치 기반 워크플로우입니다. 이 가이드는 GitHub Flow가 어떻게 그리고 왜 작동하는지 설명합니다.
이 문서는 [원본 기사 링크 포함]의 비공식적 번역이며 승인 또는 유지되지 않습니다. 공식 도움말은 help.github.com을 방문하세요 .
Create a branch
프로젝트를 진행할 때 여러 가지 요구사항이 발생할 것입니다. 그 중 일부는 진행이 가능하고 나머지는 그렇지 못 합니다. 브랜치는 이러한 작업을 관리하는데 도움이 됩니다.
프로젝트에서 브랜치를 생성하면 새로운 기능/아이디어를 시험할 수 있는 환경이 만들어집니다. 브랜치에서 진행되는 모든 작업은 master 브랜치에 영향을 미치지
않으므로 자유롭게 실험하고 변경 사항을 적용 할 수 있습니다.
ProTip
브랜치는 Git의 핵심 개념이며 GitHub Flow는 Git을 기반으로 합니다. 하나의 규칙만 기억합시다. master 브랜치는 항상 배포 가능해야 합니다.
이러한 이유 때문에 새로운 브랜치를 master에서 생성하는 것이 매우 중요합니다. 그리고, 브랜치의 이름은 한 눈에 어떤 작업을 위한 브랜치인지 알 수 있는
이름을 가져야 합니다.(e.g., refactor-authentication,
user-content-cache-key, make-retina-avatars)
Add commits
파일을 추가, 수정 또는 삭제할 때마다 커밋하여 작업 히스토리를 남겨야 합니다.
작업자가 작업을 진행한 이유를 다른 작업자들이 이해할 수 있도록 커밋이 이루어져야 합니다. 각 커밋에는 커밋 메시지가 있으며 이는 특정 변경이 이루어진 이유를 설명합니다. 또한 각 커밋은 별도의 변경 단위로 간주됩니다. 이렇게하면 버그가 발견되거나 요구 사항이 수정될 경우 변경 사항을 롤백 할 수 있습니다.
ProTip
커밋 메시지는 중요합니다. 명확한 커밋 메시지를 작성하면 다른 사람들이 쉽게 이해하고 피드백을 제공 할 수 있습니다.
Open a Pull Request
Pull Request로 커밋에 대한 토론을 시작합니다. 각각의 작업 브랜치들은 기본 Git 저장소와 긴밀하게 통합되어 있기 때문입니다. 요청을 수락하면 변경 내용을 master 브랜치에 병합 할 수 있습니다.
개발 중이라도 언제든 Pull Request를 요청할 수 있습니다.(코드가 거의 없거나 스크린샷/아이디어를 공유하려는 경우, 도움이 필요한 경우 또는 코드 리뷰가 필요한 경우) Pull Request 메시지에서 GitHub의 @mention을 사용하여 특정 대상에게 피드백을 요청할 수 있습니다.
ProTip
Pull Requests are useful for contributing to open source projects and for managing changes to shared repositories. If you're using a Fork & Pull Model, Pull Requests provide a way to notify project maintainers about the changes you'd like them to consider. If you're using a Shared Repository Model, Pull Requests help start code review and conversation about proposed changes before they're merged into the master branch.
Discuss and review your code
Pull Request 요청이 오면 검토하는 사람 또는 팀에서 수정 사항에 대한 질문이나 의견이 있을 수 있습니다. 아마도 코드 스타일이 가이드 라인과 일치하지 않을 수도 있고 단위 테스트가 없을 수도 있습니다. Pull Request는 이러한 유형의 대화를 장려하고 포착할 수 있도록 설계되었습니다.
또한 커밋에 대한 토론과 피드백을 토대로 계속해서 브랜치에 푸시할 수 있습니다. 만약 무엇인가 빠뜨렸거나 버그가 있을 경우 해당 부분을 수정하고 변경 사항을 적용 할 수 있습니다. GitHub는 새로운 커밋과 추가 피드백을 모두 보여줍니다.
ProTip
Pull Request 코멘트는 마크다운으로 작성되므로 이미지와 이모티콘, 미리 작성된 텍스트 블록이나 간단한 서식을 사용할 수 있습니다.
Deploy
master에 병합하기 전에 마지막 테스트를 진행할 수 있습니다.
Pull Request 요청을 검토하고 테스트를 통과하면 변경 사항을 배포하여 프로덕션 환경에서 확인할 수 있습니다. 만약 브랜치에서 문제가 발생하면 기존 마스터를 프로덕션 환경에 배포하여 롤백이 가능합니다.
Merge
프로덕션 환경에서 검토가 완료되면 변경 사항을 master 브랜치에 병합해야합니다.
병합되면 Pull Request 요청은 코드의 변경 히스토리를 저장합니다. 언제든지 해당 작업에 대해 검색해서 어떠한 결정을 내린 이유와 방법을 이해할 수 있습니다.
ProTip
Pull Request의 텍스트에 특정 키워드를 통합하여 이슈를 코드와 연결할 수 있습니다. Pull Request가 승인되면 관련 이슈도 완료됩니다. 예를 들어 Close #32라는 문구를 입력하면 32번 이슈가 닫힙니다. 자세한 내용은 Help article을 확인하세요.
Github, Understanding the github flow, Github Guide, Last updated Nov 30, 2017 / Last translated Nov 30, 2018, https://guides.github.com/introduction/flow/
- 2018-12-12 페이지 하단에 출처 표기
- 2018-12-12 Github staff의 가이드에 따라 페이지 상단에 면책 조항 작성