답변:
이상적으로 당신 :
새로운 기능 요청 인 경우 먼저 코딩을 시작하지 마십시오. 새로운 기능에 대해 논의하려면 이슈를 게시하십시오.
기능에 대해 잘 설명하고 +1 또는 프로젝트 소유자가 승인 한 경우 문제를 직접 할당 한 다음 위의 단계를 수행하십시오.
일부 프로젝트는 풀 요청 시스템을 사용하지 않습니다. 코드를 프로젝트로 다시 가져 오는 가장 좋은 방법은 작성자 또는 메일 목록을 확인하십시오.
Yann의 답변에 추가하기 위해 프로젝트를 분기하면 원하는 분기 (새로운 프로젝트 또는 원래 프로젝트의 분기)에서 개발할 수 있습니다
기억해:
origin', origin포크의 결과이므로 자신의 저장소이므로)git checkout master; git pull;동일 (기능 지점이 먼저 병합 된 지점) "pull vs pull --rebase"와 "merge vs rebase"를 읽은 후에는 단순한 역사입니다. 더 깊은 것이 있습니까?
Yan과 VonC의 답변에 추가하기 위해 이것은 github 자체의 좋은 자료입니다 : http://help.github.com/forking/
또한 "협업"제목 아래의 오른쪽 사이드 바를 확인하십시오.
Github에는 여러 가지 방법으로 프로젝트를 공동 작업 할 수 있습니다. 대부분의 프로젝트 사용 모델은 풀 요청 모델입니다. 사람들이 처음 GitHub 풀 요청을 할 수 있도록 프로젝트를 시작했습니다. 실습 자습서를 통해 첫 번째 PR 을 만들 수 있습니다.
워크 플로우는 다음과 같이 간단합니다.
git push origin branch-nameCompare and pull request버튼 을 보려면 GitHub의 포크로 이동하십시오lornajane은 프로세스를 잘 설명하는 블로그 게시물을 가지고 있습니다. http://www.lornajane.net/posts/2010/contributing-to-projects-on-github
다음과 같은 워크 플로를 제안합니다.
복제 (명령 줄에서)
git clone <url-from-your-workspace>
방금 만든 디렉토리를 입력하고 지점을 만듭니다.
cd <directory>
git checkout -b <branchname>
이제 변경하십시오
각 변경 후 하나 이상의 커밋을 만들 수 있습니다.
commit -a
완료되면 변경 사항을 푸시하십시오.
git push origin <branch>
명령 행 에 PR을 작성하기위한 URL 이 표시 되어야합니다 . URL을 방문하여 버튼을 클릭하여 PR을 만드십시오.
그렇지 않은 경우 브라우저의 저장소를 방문하면 풀 요청을 작성하기위한 단추가 제공됩니다.
그게 다야.
따라서 기본적으로 저장소를 작업 공간으로 분기하고 새 분기를 작성하고 새 분기를 푸시했습니다.
나중에 동일한 복제 된 리포지토리에서 더 많은 PR을 만드는 경우 다른 PR에 대한 다른 분기를 만들기 전에 동기화해야합니다 (원래 저장소에서 최신 변경 사항 가져 오기).
git checkout master
git remote add upstream <url-of-original-repo>
git pull upstream master
이러한 제안은 통합되지 않는 PR에 작업을 수행하는 데 따르는 문제를 해결하기 위해 제공됩니다. 프로젝트에 활동이 있고 PR이 병합되면 이는 좋은 신호입니다. 컨트 리뷰 션 가이드 라인이있는 경우이를 따르십시오.
항상 정중하십시오. 프로젝트 관리자는 PR을 병합 할 의무가 없습니다. 프로젝트에 추가 할 가치가있는 것이 있습니까?