프로젝트 확장 포크를 유지 관리하기위한 워크 플로우?

Question

우리는 GitHub에서 OSS 프로젝트를 포크했으며 일부 사용자 정의 확장을 추가했습니다. 우리는 변경 사항 중 일부를 원래 프로젝트 (버그 수정 등)로 보내고 싶지만 다른 변경 사항은 원래 프로젝트 관리자가 지금은 관심이없는 기능 확장입니다. 이 상황을 관리하기위한 최상의 워크 플로를 파악하려고합니다.

원본 브랜치 (원래 프로젝트의 커밋) + (기여 버그 수정) + (사용자 정의 확장)를 마스터 브랜치에 포함시키고 싶습니다. 버그 수정을 사용자 정의 확장과 분리하여 유지할 수 있도록 지점마다 기능 모델을 원한다고 생각합니다. 우리는 master 브랜치에서 커스텀 확장 브랜치를 시작할 수 있지만, 원래의 프로젝트를 추적하는 로컬 "origin"브랜치 나 다른 것을 유지하고 싶어한다. 맞춤 물건. 또는 뭔가.

누구나이 워크 플로우를 구조화하는 최선의 방법을 제안 할 수 있습니다. 따라서 모든 다양한 커밋이 이동해야하는 위치로 이동하고 이동하지 않아도되는 위치로 이동하지 않아도됩니다.

Answer 1

당신이 이미 자신의 질문에 대답 한 것처럼 들리는군요. "vanilla"라는 브랜치를 생성하거나 업스트림의 마스터 브랜치를 추적하고 사용자 정의 확장을 포함하는 "master"브랜치를 만듭니다. 자신이하는 각각의 일에 대해 가지를 만듭니다. 버그 수정의 경우 "바닐라"로 시작하십시오. 자신의 물건에 대해서는 마스터에게서 시작하십시오. 매번 바닐라를 마스터로 합치십시오. 사용자 정의 확장 분기에 버그 픽스를 얻으려면 분기를 마스터에 직접 병합하거나 업스트림이 bugfix 풀 요청을 수락 할 때까지 기다린 다음 바닐라에서 마스터로 다음 병합 할 때 버그 픽스가 포함될 수 있습니다. 이것은 매우 일반적인 워크 플로우처럼 보입니다.

Answer 2

장기 포크이 작업은 이미 솔루션이 "바닐라"프로젝트와 연결된 특수 분기를 설정하고 유지 관리하는 지점을 가질 수 있음을 알기 때문에 수행해야합니다 귀하의 커스텀 작업 카피.

당신이 명심해야 할 유일한 것은 (내 관점에서) 당신이 변화를 동기화하고 싶을 때 두 가지를 병합,하지만해야한다는 것입니다이 경우 (지점은을 분기하는 경우)이 Git Cherry-Pick 명령 하나의 분기에서 하나의 커밋을 받아서 다른에 적용 할 수 있습니다. 이것은 한 분기에서 다른 분기로 단일 커밋을 쉽게 교환 할 수 있기 때문에 포크 유지 보수의 경우 특히 유용 할 수 있습니다. .