Qual é a etiqueta adequada e o fluxo de trabalho recomendado do GitHub para contribuir e divergir simultaneamente do repo upstream?

Eu sou novo no GitHub e VCS em geral. Venho programando em vários idiomas há anos, mas sempre trabalhei sozinho em projetos personalizados (sem lançamentos públicos). Recentemente, comecei a usar um widget da UI do jQuery que baixei do GitHub em um projeto em que estou trabalhando. O repo não é mais mantido pelo autor original. Outro garfo incorporou alguns dos pedidos de recebimento originais. Este é o que eu bifurquei.

Encontrei alguns bugs e criei as correções para eles. Eu gostaria de contribuir com essas correções, mas também tenho muitas outras alterações que quero fazer, para nosso próprio uso, que quebrarão alguns dos recursos existentes. Além disso, gostaria de incorporar uma ideia de outro garfo.

Ainda estou aprendendo GIT e GitHub e estou tentando descobrir a melhor maneira de fazer tudo. Eu li muito (aqui, SO, páginas de ajuda do GitHub, Pro Git) sobre diferentes conceitos / tarefas: fluxos de trabalho, mesclagens, solicitações pull, seleção de cereja, rebasing, ramificação. Minha massa cinzenta está nadando e preciso começar a entender para entender melhor o que li.

Questões principais:

1. Acho que li (em algum lugar) que você só pode ter uma solicitação de recebimento em uma filial por vez. Então, isso significa que eu deveria ter uma ramificação separada para cada bug e, em seguida, fazer uma solicitação pull separada para cada um?

2. Quero limpar problemas de espaço em branco e me lembro de ler que é melhor fazer isso em um commit separado. Devo fazer isso no meu mestre ou em um ramo separado? Não quero fazer uma solicitação pull por algo tão trivial , mas se eu fizer alterações no espaço em branco antes da ramificação, isso afetará a solicitação pull para as correções de bugs? Alguns garfos limparam os espaços em branco e efetivamente tornaram a diferença bastante inútil.

3. Eu estava pensando em criar problemas no meu fork como uma maneira de documentar os erros, mesmo que eu já tenha a correção para eles. Essa é uma boa ideia? Como faço para vincular o problema, a confirmação e a mesclagem ao domínio? Se eu fizer uma solicitação pull a montante, meu problema também aparecerá a montante ou o link da documentação será perdido? Não consigo abrir um problema no repositório upstream (não há guia de problemas).

4. Qual é a melhor maneira de dar crédito ao outro autor da bifurcação pela ideia dele que eu quero usar? Não posso usar exatamente o código dele, principalmente porque a alteração é aplicada a uma versão mais antiga do upstream e não é compatível com minhas outras alterações. Mas quero usar a ideia e dar crédito onde o crédito é devido. Devo apenas vincular ao seu repositório (ou perfil ou confirmação específica) na minha mensagem de confirmação?

5. Qual é a etiqueta em relação à alteração do arquivo leia-me e do DocBlock na parte superior do arquivo principal? Posso fazer alterações, adicionar meu nome, adicionar links ao meu repositório e demo, remover links para o demo original (já que meu fork será incompatível com o original)? Obviamente, deixarei o nome do autor original e as informações da licença. Para o registro, é licenciado sob a licença MIT.

Como desenvolvedor solo que nunca usou o VCS, estou acostumado a reescrever a história . Sou perfeccionista e gosto de coisas limpas e arrumadas. A idéia da história registrada está me deixando um pouco nervosa e quero fazer certo da primeira vez . Criei um novo repositório para brincar / aprender, mas estou ansioso para começar a consertar o widget da interface do usuário do jQuery para que eu possa continuar com o meu projeto.

1. Correto: uma solicitação de recebimento está vinculada a uma ramificação em seu repositório. Se você modificar a ramificação, também estará modificando o que está enviando como solicitação de recebimento.

   Então, sim, você precisa criar uma ramificação (e solicitação de recebimento) por correção de bug. Pode ser aconselhável começar com um e ver como o mantenedor reage a ele antes de fazer o resto. Código aberto é um processo inerentemente social.

2. Faça um pedido de pull para suas alterações de espaço em branco! Falando como alguém que às vezes é um mantenedor, eu amo esses tipos de solicitações de recebimento: eu as aprovo ou não, e elas levam pouco tempo para serem processadas.

   O que você também pode encontrar é que o mantenedor não concorda com as alterações no espaço em branco! Então, tenha cuidado ..

3. Hmm .. Não está claro o que você está tentando alcançar aqui. Parece excesso de documentação e não é uma boa ideia - talvez você possa esclarecer por que deseja fazer isso?

4. Vincular ao repositório dele na sua mensagem de confirmação (ou mesmo em um comentário no código) é uma ótima maneira de dar crédito. Mas tenha cuidado - explique que você está agradecendo por suas idéias e não por seu código. Se você copiou o código, eu o enviarei por e-mail, a menos que seja muito claro qual licença ele está usando para seu código. Se o licenciamento for claro (e for uma licença diferente do repositório para o qual você está enviando o commit), será necessário adicionar a licença diferente na solicitação de recebimento e também mencionar isso na mensagem de solicitação de recebimento.

5. Essa é uma pergunta muito boa e varia de acordo com quem você fala. Minha opinião é que você nunca deve adicionar seu nome a nenhum commit ou código que fizer. O principal motivo é que implica "propriedade e responsabilidade pelo código" - isso pode impedir que outras pessoas modifiquem o código porque "é seu". Mas agora estamos entrando em uma enorme discussão sobre a natureza do código aberto, então vou parar por aqui e dizer - pergunte ao mantenedor do projeto ou apenas faça e veja qual é a reação dele.

6. Você pode reescrever o histórico (seu local, ainda não publicado) com o GIT! Aprenda o comando git rebase - esse é um dos principais motivos pelos quais eu amo o git. É uma muito má ideia (força) commits impulso reescritos / história para o repositório compartilhado (github, por exemplo). Isso vai estragar os repositórios que os outros desenvolvedores têm - eles terão que fazer coisas difíceis ao extrair suas alterações (histórico reescrito).

[# 6: Obrigado, @toxalot!]