Qual é o melhor fluxo de trabalho do Git para trabalhar com um projeto de código aberto com alterações específicas do empregador?

No meu atual empregador, estamos usando um projeto de código aberto hospedado no Github como um componente de nosso aplicativo. Eu tenho trabalhado neste projeto para adicionar alguns recursos necessários e integrá-lo aos nossos sistemas de compilação. Meu gerente e eu concordamos que gostaríamos de enviar o máximo possível de nosso trabalho neste componente para o projeto de código aberto. Minha pergunta é sobre qual é a melhor técnica / fluxo de trabalho para manter meus compromissos do Git de forma que eu possa separar facilmente coisas que fazem sentido adicionar novamente ao projeto de código aberto - correções de bugs e novos recursos suficientemente gerais - de coisas específicas do nosso projeto, como locais de construção e constantes de aplicativos.

O que tenho feito até agora é manter uma ramificação privada do Git em que confirmo todas as minhas alterações, com granularidade apropriada. Eu então uso cherry-pickpara adicionar as confirmações de código aberto à ramificação principal e enviá-las de volta ao Github.

Parece que eu deveria estar usando a mesclagem para fazer isso, para não continuar criando confirmações separadas com conteúdo idêntico, mas não sei como fazer isso, excluindo as confirmações específicas da empresa e mantendo um fluxo de trabalho razoável.

Por exemplo, suponho que eu poderia comprometer itens de código aberto em itens mestre e específicos da empresa na ramificação privada e, em seguida, mesclar o mestre nessa ramificação conforme necessário, deixando o ramo mestre apontando para a confirmação antes da mesclagem, para que eu pudesse comprometa coisas de código aberto a ele novamente e depois mescle novamente. O que parece estranho neste fluxo de trabalho é que eu precisaria decidir com antecedência sobre tudo o que faço a qual ramo ele pertencia, trabalhar sobre o que parecia conclusão, depois enviá-lo e mesclá-lo antes do teste. Uma das coisas de que realmente gosto no Git é como é fácil fazer o que for necessário para que seu aplicativo funcione e depois decidir mais tarde como e onde confirmar suas alterações. Até onde eu sei, se você está atualmente em uma filial e tem algum trabalho concluído,

O que estou fazendo é um fluxo de trabalho razoável para contribuições de longo prazo? Alguém pode recomendar um fluxo de trabalho diferente que possa ser melhor e por que é melhor?

Aqui está uma estratégia que pode funcionar para você:

Crie 2 repositórios Git privados, sendo um repositório para o trabalho da empresa e outro o repositório geral (eu gostaria de confirmar).

Para que este sistema funcione, você precisa fazer o seguinte (que considero a estratégia mais importante): Definir o que é "geral" e pode ser usado por todos os demais membros da comunidade.

Por ter essa definição, é possível separar o que você confirmará e o que não precisará confirmar.

Faz sentido que o que você codifique para a comunidade seja de uma forma geral, pois um pedaço de código muito específico não beneficiará ninguém (e talvez nem chegue ao ramo mestre).

Agora que você sabe o que vai comprometer com a comunidade, pode fazer a maior parte do trabalho de "devolução" no repo dedicado a ela. Em seguida, basta passar o repositório para o repositório baseado no trabalho e executar qualquer trabalho específico do trabalho.

Eu suspeito que você passará muito mais tempo no repositório de "devolução", então lembre-se de fornecer comentários valiosos, etc. (talvez até documentação) para as pessoas que usariam esse projeto no futuro.

Eu também acredito que o git pode fazer muito mais do que você pensa. Eu assisti esse vídeo no Vimeo: http://vimeo.com/46010208 e ela fez um trabalho brilhante ao explicar muitas coisas malucas que o git pode fazer.

Minha estratégia não é a única por aí, mas pode definitivamente ser um ponto de partida para você pensar em uma que melhor lhe convenha.

Dependendo da natureza da base de código de código-fonte aberto e o que você precisa alcançar ao fazer alterações, você pode obter muita milhagem separando suas preocupações. Na sua bifurcação do projeto, adicione apenas as coisas que você pretende contribuir de volta ao original. Adicione ganchos ou pontos de extensão para permitir que você faça um trabalho em sua empresa que não será compartilhado.

Dessa forma, você nunca precisará se preocupar em dividir ou decidir com antecedência o que compartilhar e o que não compartilhar. Como você adicionou flexibilidade ao projeto original, sempre pode optar por compartilhar algumas partes do trabalho da sua empresa posteriormente.