그래서 GitHub 에서 실제 프로젝트를 시작 했으며 상황이 꽤 잘 진행되고 아이디어가 처음에 생각했던 것보다 훨씬 빠르게 흐릅니다. 일을 체계적으로 유지하기 위해 여러 가지 기능을 별도로 개발할 수 있도록 지점을 설정했습니다.
: 나는 GitHub의 내 지점을 밀어 자 할 때, 나는 내가 두 개의 버튼이 절로 Pull Request과 Compare나는 최근에 푸시 지점의 이름을. Compare버튼 의 목적을 이해 하지만 자체 리포지토리에 풀 요청을 생성하려는 이유를 알 수 없습니다.
누군가 내가 왜 그렇게 할 수 있는지 설명해 줄 수 있습니까? 내가 유일한 개발자 인 경우 내 리포지토리에 끌어 오기 요청을하는 것이 유용합니까?
답변:
자체적으로 작업하는 많은 (아마도 대부분의) 개별 개발자에게 풀 요청을 작성하는 것은 가치가 없을 것입니다. 그러나 적어도 하나의 잠재적 이유를 생각할 수 있습니다.
풀 요청을 사용하면 프로젝트 기록을보다 쉽게 추적 할 수 있습니다. 풀 요청에는 커밋 메시지 및 변경 로그에서 참조 할 수있는 문제 ID가있어 기능을 유지하지 않고도 특정 변경에 대한 병합 지점 및 병합 된 커밋 세트로 쉽게 되돌아 갈 수 있습니다. 무기한 가지.
예를 들어 Pioneer (shameless plug)에서 풀 요청을 병합하면 변경 에 대한 한 줄 설명과 풀 요청 ID에 대한 참조가 있는 항목을 changelog에 추가합니다 . 물론 파이오니어에는 여러 개발자가 있지만 동일한 메커니즘이 개발자 자신의 개발자에게 유용 할 수 있습니다.
선형 커밋 히스토리를 고수하기로 결정한 경우 (병합 전에 피처 브랜치를 리베이스하여 병합을 항상 빨리 진행할 수 있도록), 편집 및 스쿼시에 대해 잘 훈련 된 경우 유용하지 않을 수 있습니다. 이 경우 개별 커밋 메시지가 자체적으로 변경 로그로 사용될 수 있기 때문에 마스터에 병합하기 전에 커밋합니다.
풀 요청이 작성되어 누군가가 작업을 검토하고, 의견을 제시하거나, 제안하거나, 편집하거나 요청한 다음 코드를 마스터로 병합 할 수 있습니다.
귀하의 경우 누군가가 당신입니다.
유일한 개발자는 여전히 자신의 작업을 검토하고 리팩터링하여 준비가되면 마스터로 병합해야합니다.
내가 많이 사용하는 한 가지 접근 방식은 '다른 모자를 쓰고', '다른 인물을 시도'하는 것입니다. 따라서 잠시 동안 앉아서 다음과 같은 상황에 처하십시오. 주니어 개발자; 과거에 존중했던 동료 등. 눈을 통해보고, 변화를보다 명확하게하고 가능한 한 부족과 영역 지식을 최대한 피할 수있는 더 나은 이름으로 더 잘 작성하기 위해 무엇을 할 수 있을지 생각해보십시오. .
따라서 표시된 것처럼 마스터에 준비되지 않은 기능과 변경 사항을 분리하려는 경우 지점에서 작업해야합니다. 브랜치에서 모든 작업을 수행 할 수 있습니다 (PR 작업을 수행하는 경우 풀 요청이 필요하지 않지만 유용한 구조를 제공 할 수 있음).
또한 때로는 변경 사항이 작동하지 않는 것을 알 수 있지만 마스터에서 변경하려고하는 공포보다는 오히려 다른 마스터 변경 사항과 혼합 될 수 있습니다. 지점에서 모든 작업을 수행 할 수 있습니다. / 잘못 시작하면 삭제하십시오. 이것은 큰 이점입니다.
따라서 전체 지점을 병합하기로 결정할 때까지 지점에서 작업 하고 마스터에 직접 커밋 하지 않아야 합니다 .
다음은 규칙이 아니라 지침입니다. 때로 고의로 깰 수도 있습니다. 예를 들어, 어제 나는 오타 수정을 마스터했습니다.
원격 지점과 로컬 지점이있는 것처럼 들립니다. 해당 워크 플로의 오버 헤드를 너무 많이 찾는 경우 로컬 분기를 사용하여 다른 기능을 사용하지 않고도 언제든지 작업 할 수 있습니다.
그것은 기본적으로 당신에게 맞는 일을하게됩니다. 브랜치 작업은 git의 큰 이점이며, github는이를 매우 쉽게 만들어줍니다. 그러나 고독한 개발자는 풀 요청 모델을 사용할 필요가 없으며 마스터에 직접 커밋하는 것이 잘 작동합니다. 프로젝트가 결국 성공을 거두고 수십 또는 수백 명의 개발자가 프로젝트를 진행할 때 포크에서 풀 요청을 얻는 것이 프로젝트를 추적하는 좋은 방법임을 알게 될 것입니다.
풀 요청 대 git push는 궁극적으로 개인 또는 공유 기록 중 하나로 내려갑니다. 기본 리포지토리는 모든 변경의 소스이며, 다른 사람들이 로컬 변경을 가져오고 잠재적으로 변경하는 경우 푸시 요청으로 인해 해당 사용자가 변경에서 파생 된 트리로 인해 문제가 발생할 수 있습니다.
풀 요청 모델 (사용자 정의 브랜치 또는 개인 저장소에서)은 코드를 사용하거나 코드에서 파생하는 모든 사용자에게 일관된 히스토리를 제공하는 방법으로 사용됩니다.
github에 코드를 넣는 이유 중 일부는 코드를 fork 및 pull 요청에 사용할 수있게 만드는 것입니다. 언제 일어날 지 알 수 없으며 공동 개발자의 역사를 일관되게 유지하는 것이 큰 장점입니다.