고용주 별 변경 사항이있는 오픈 소스 프로젝트 작업에 가장 적합한 Git 워크 플로우는 무엇입니까?

현재 고용주에서는 Github에서 호스팅되는 오픈 소스 프로젝트를 응용 프로그램의 구성 요소로 사용하고 있습니다. 필자는이 프로젝트에서 필요한 기능을 추가하고이를 빌드 시스템과 통합하기 위해 노력하고 있습니다. 관리자와 저는 오픈 소스 프로젝트에 합당한만큼이 구성 요소에 대한 우리의 작업을 제출하고 싶다는 데 동의합니다. 내 질문은 오픈 소스 프로젝트에 다시 추가 할 수있는 것들을 쉽게 분리 할 수있는 방식으로 Git 커밋을 유지하는 가장 좋은 워크 플로우 / 기술에 관한 것입니다-버그 수정 및 충분히 일반적인 새로운 기능- 빌드 위치 및 응용 프로그램 상수와 같이 프로젝트와 관련된 것에서

내가 지금까지 한 일은 적절한 세부 단위로 모든 변경 사항을 커밋하는 개인 Git 브랜치를 유지하는 것입니다. 그런 다음 cherry-pick오픈 소스 커밋을 마스터 브랜치에 추가하고 Github에 다시 제출합니다.

병합을 사용하여 동일한 내용으로 별도의 커밋을 계속 생성하지는 않지만 회사 별 커밋을 제외하고 합리적인 워크 플로우를 유지 하면서이 작업을 수행하는 방법을 모르겠습니다.

예를 들어 개인 지점의 마스터 및 회사 특정 항목에 오픈 소스 가능 항목을 커밋 한 다음 필요에 따라 마스터를 해당 지점으로 병합하여 마스터 분기가 병합 전에 커밋을 가리 키도록 할 수 있다고 가정합니다. 오픈 소스 가능 항목을 다시 커밋 한 다음 다시 병합하십시오. 이 워크 플로에서 어색한 점은 내가 속한 브랜치에 대한 모든 작업을 미리 결정하고 완료된 것처럼 작업 한 다음 커밋하고 테스트하기 전에 병합해야한다는 것입니다. Git에서 정말 좋아하는 것 중 하나는 응용 프로그램을 작동시키는 데 필요한 모든 작업을 수행 한 다음 나중에 변경 내용을 커밋 할 방법과 위치를 결정하는 것이 얼마나 쉬운 지입니다. 내가 알 수있는 한, 현재 지점에 있고 몇 가지 작업을 수행했다면

장기 기여를 위해 합리적인 워크 플로를 수행하고 있습니까? 누구나 더 나은 다른 워크 플로를 추천 할 수있는 이유는 무엇입니까?

귀하에게 적합한 전략은 다음과 같습니다.

하나는 리포지토리이고 다른 하나는 일반적인 리포지토리 인 리포지토리로 개인 리포지토리를 2 개 만듭니다.

이 시스템을 작동 시키려면이 작업을 수행해야합니다 (가장 중요한 전략이라고 생각합니다). "일반"을 정의하고 커뮤니티의 다른 사람이 사용할 수있는 대상 정의

이 정의를 통해 커밋 할 내용과 커밋 할 필요가없는 항목을 분리 할 수 ​​있습니다.

코드를 너무 구체적으로 지정하면 아무도 혜택을 얻지 못하고 (마스터 브랜치로 만들지 않을 수도 있기 때문에) 커뮤니티를 위해 코딩하는 것이 일반적인 형식으로되어 있다는 것이 합리적입니다.

이제 커뮤니티에 무엇을 할 것인지 알았으므로 해당 리포지토리에서 대부분의 "기부"작업을 수행 할 수 있습니다. 그런 다음 단순히 해당 리포지를 작업 기반 리포지토리로 포크하고 그 위에 작업 별 작업을 수행하십시오.

"백백 (back-back)"리포지토리에서 더 많은 시간을 할애 할 것 같으므로 앞으로 해당 프로젝트를 사용할 사람들에게 소중한 의견 등을 제공해야합니다.

또한 git은 생각보다 많은 것을 할 수 있다고 생각합니다. Vimeo에서이 비디오를 보았습니다 : http://vimeo.com/46010208 그녀는 git이 할 수있는 많은 엉뚱한 일을 설명하는 훌륭한 일을했습니다.

내 전략이 유일한 전략은 아니지만, 구체적으로 자신에게 맞는 1을 생각하는 출발점이 될 수 있습니다.

오픈 소스 코드베이스의 특성과 변경하여 달성해야 할 사항에 따라 문제를 분리하여 많은 마일리지를 얻을 수 있습니다. 프로젝트 포크 에는 원본에 다시 제공하려는 항목 만 추가하십시오. 공유되지 않는 회사 작업을 수행 할 수 있도록 후크 또는 확장 점을 추가하십시오.

이렇게하면 공유 할 항목과 공유 할 항목을 미리 나누거나 결정할 때 걱정할 필요가 없습니다. 원래 프로젝트에 유연성을 추가했기 때문에 나중에 회사 작업의 일부를 공유하도록 선택할 수 있습니다.