GitHub guide - GitHub flow

GitHub flow

프로젝트들에 협력하며 GitHub의 플로우를 따라보세요

---

소개

---

GitHub 플로우는 가볍고 브랜치기반의 작업흐름입니다. GitHub 플로우는 개발자뿐만 아니라 모두에게 유용합니다. 여기 GitHub를 예를 들자면, 우리는 GitHub 플로우를 우리의 site policy, documentation, 그리고 roadmap에 사용했습니다.

 

 

 

사전 조건

---

GitHub 플로우를 따르기 위해선 GitHub 계정과 레포지토리가 필요합니다. 계정을 만들기 위한 방법에 대해 더 많은 정보가 필요하다면 "Signing up for GitHub"를 참고하세요. 레포지토리 생성 방법에 대한 더 많은 정보를 원한다면 "Create a repo"를 참고하세요. 존재하는 레포지토리를 찾고 공헌하는 것에 대해서 궁금하다면 "Finding ways to contribute to open source on GitHub"를 참고하세요.

 

 

 

GitHub 플로우 따라가기

---

팁: 당신은 GitHub의 모든 스텝을 GitHub 웹 인터페이스, 명령줄 그리고 GitHub CLI 또는 GitHub Desktop을 통해 완성할 수 있습니다.

 

 

브랜치 생성하기

당신의 레포지토리 안에 브랜치를 생성하세요. 짧고 묘사적으로 브랜치 이름은 당신의 협력자들이 작업중인 업무를 한 눈에 이해할 수 있게 합니다. 예를 들면,  increase-test-timeout  또는  add-code-of-conduct 입니다. 더 자세히 알고 싶다면 "Creating and deleting branches within your repository"를 참고하세요.

 

브랜치를 생성함으로써, 당신은 디폴트 브랜치에 영향을 주지 않고 작업할 수 있는 공간을 만들었습니다. 게다가 당신은 협력자들에게 당신의 작업을 검토할 기회를 줍니다.

 

 

변경 사항 만들기

당신의 브랜치에서, 레포지토리에 요구되는 변경 사항들을 만드세요. 더 자세히 알고 싶다면 "Creating new files", "Editing files", "Renaming a file", "Moving a file to a new location", 또는 "Deleting files in a repository"를 살펴보세요.

 

당신의 브랜치는 변경 사항을 만들기에 안전한 공간입니다. 만약 당신이 실수를 한다 하더라도, 당신은 변경 사항을 되돌리거나 실수를 바로잡기 위한 추가적인 변경사항을 올릴 수 있습니다. 당신의 브랜치를 머지할 때 까지 당신의 변경 사항들은 기본 브랜치에서 끝나지 않습니다.

 

당신의 브랜치에 변경 사항들을 commit하고 push하세요. 당신과 미래의 협력자들이 커밋이 무슨 변경 사항을 담고 있는 지 이해하도록 돕기 위해 각 커밋에 설명 메시지를 달아주세요. 예를 들면,  fix typo  또는  increase rate limit 등이 되겠습니다.

 

이상적으로, 각 커밋은 독립되고 완벽한 변경 사항을 포함합니다. 이것은 당신이 다른 방식의 접근법을 선택하여 실행할 때 변경 사항을 쉽게 되돌릴 수 있게 해줍니다. 예를 들어 만약 당신이 변수 이름을 재설정하고 몇가지 테스트를 추가하길 원한다면, 한 커밋에 변수 이름을 재설정하고 다른 커밋에서 테스트를 하는 것입니다. 만약 당신이 나중에 테스트는 유지하고 변수 이름들을 되돌리고 싶다면, 당신은 변수 이름을 재설정한 커밋을 되돌리면 됩니다. 만약 당신이 이름을 재설정한 변수들과 테스트를 같은 커밋에 두고싶거나 재설정한 변수들을 여러 커밋에 두고싶다면 후에 변경 사항을 되돌리고 싶을 때 더 많은 시간과 노력이 필요합니다.

 

당신의 변경 사항을 커밋하고 올림으로써 당신의 작업을 원격 저장소에서 백업할 수 있습니다. 이것은 당신이 어떤 기기에서나 당신의 작업에 접근할 수 있다는 것을 의미합니다. 또한 당신의 협력자들이 당신의 작업을 보고, 질문을 하며, 기여 또는 제의를 할 수 있다는 뜻입니다.

 

당신이 피드백을 구할 준비가 될 때까지 브랜치에 변경 사항을 만들고, 커밋하여 올리는 것을 계속하세요.

 

팁: 관련없는 각각의 변경 사항을 위해서 분리된 브랜치를 만드세요. 이것은 검토자들이 피드백을 주기 쉽게 만들어줍니다. 또한 후에 있을 당신의 협력자들이 변경 사항을 쉽게 이해하거나 또는 되돌리거나 또는 그들 위에 작성할 수 있게 해줍니다. 게다가 만약 한 세트의 변경 사항에 지연이 있더라도 다른 변경 사항들은 지연되지 않습니다.

 

 

pull 요청 생성하기

당신의 변경 사항에 대해 협력자들에게 pull 요청을 생성하세요. pull 요청 검토는 매우 중요하기 때문에 몇 레포지토리는 병합(merge)되기 전에 승인 검토가 필요합니다. 만약 당신이 당신의 변경 사항을 완료하기 전에 이른 피드백이나 조언을 원한다면, 당신의 pull 요청을 초안으로서 표시해둘 수 있습니다. 더 자세히 알고 싶다면 "Creating a pull request"를 참고하세요.

 

당신이 pull 요청을 생성할 때, 변경 사항에 대한 요약을 포함하고 그들이 어떤 문제를 해결했는지 포함합니다. 당신은 이미지와 링크, 이 정보를 전달하는데 도움을 줄 테이블들을 포함할 수 있습니다. 만약 당신의 pull 요청이 이슈에 대해 다루고있다면, 이슈를 링크하여 이해당사자들이 이슈에 대해 인지할 수 있도록 합니다. 반대의 경우도 마찬가지입니다. 만약 당신이 키워드를 링크한다면, pull 요청이 병합할 때 이슈는 자동적으로 닫힙니다. 더 자세히 알고 싶다면 "Basic writing and formatting syntax"와 "Linking a pull request to an issue"를 참고하세요.

pull 요청의 본문을 작성할 뿐만 아니라 pull요청의 특정 행에 주석을 추가하여 검토자에게 분명하게 지정할 수 있습니다.

당신의 레포지토리는 pull 요청이 생성되었을 때 특정한 팀이나 유저로부터 자동적으로 검토를 요청하도록 구성될 수 있습니다. 또한 직접 @멘션 또는 특정한 팀 또는 사람에게 검토를 요청할 수 있습니다.

 

만약 당신의 레포지토리가 pull 요청에 대해 실행도록 구성되어 검사를 한다면, 당신은 pull 요청에 실패한 검사를 볼 수 있습니다. 이것은 당신이 브랜치에 병합하기 전에 에러를 잡는데 도움을 줍니다. 더 자세히 알고 싶다면 "About status checks"를 확인하세요.

 

 

pull 요청 병합하기

당신이 pull 요청이 승인될 때, pull 요청을 병합하세요. 이것은 자동적으로 당신의 브랜치를 병합하여 당신의 변경 사항들이 기본 브랜치에 나타날 것입니다. GitHub는 미래 협업자가 당신의 변경 사항을 이해할 수 있도록 돕기 위해 pull 요청의 주석과 커밋들의 기록을 보관합니다. 더 자세히 알고 싶다면 "Merging a pull request"를 살펴보세요.

 

만약 당신의 pull 요청이 충돌을 일으켰으며 병합 전에 반드시 해결되어야 한다면 GitHub는 당신에게 알릴 것입니다. 더 자세히 알고싶다면 "Addressing merge conflicts"를 참고하세요.

 

브랜치 보호 설정은 당신의 pull 요청이 특정 요구 조건을 충족시키지 못한다면 차단합니다. 예를 들면, 당신은 특정한 팀으로부터 승인 검토 또는 일정 수의 승인 검토가 필요합니다. 더 자세히 알고 싶다면 "About protected branches"를 참고하세요.

 

 

브랜치 삭제하기

당신의 pull 요청을 병합한 후에 브랜치를 지우세요. 이것은 해당 브랜치에서의 작업이 끝났다는 것을 의미하며 당신 또는 다른 이가 오래된 브랜치를 사용하게 되는 사고를 예방합니다. 더 자세히 알고 싶다면 "Deleting and restoring branches in a pull request"를 참고하세요.

 

정보를 잃는 것에 대해서는 걱정마세요. 당신의 pull 요청과 커밋 기록은 삭제되지 않습니다. 당신이 원한다면 언제나 삭제된 브랜치를 복구하거나 pull 요청을 되돌릴 수 있습니다.