É correto pedir aos colaboradores que refiram suas solicitações pull no github

Eu mantenho um repositório github relativamente popular.

Quando uma solicitação pull é boa para mesclar, geralmente peço ao autor que a refaça novamente para uma única confirmação antes de mesclá-la (especialmente quando houver várias pequenas edições).

Essa é uma boa prática de git? Essa etiqueta é aceitável / padrão do GitHub?

Então, alguns benefícios:

Recebo um bom histórico de confirmação limpa nos logs de confirmação
Eu não preciso alterar o commit sozinho
Delega parte do trabalho

Algumas desvantagens possíveis:

Não tenho certeza se isso é uma boa etiqueta
Não tenho certeza se essa é uma boa prática de git
Normalmente, já pedi algumas outras alterações - essa é mais uma e não quero desencorajar colaboradores.

github etiquette

— Pablojim
fonte

Você pode descrever alguns benefícios e desvantagens que você vê ao fazer o processo dessa maneira?

— precisa

Vale a pena considerar alguns benefícios e desvantagens adicionais. good: git-bisect e outras reversões são mais fáceis quando cada commit produz um estado montável ou completo, e essa abordagem é uma maneira simples de garantir isso. ruim: pequenas alterações com mensagens de confirmação simples são convertidas em mega confirmações. EG "A alteração desta linha para corrigir as letras maiúsculas e minúsculas" pode ser alterada para "Adicionando recurso foo, grande lista de alterações ". Isso torna mais difícil encontrar o motivo de uma alteração específica.

— Gankro

Nada de errado em estabelecer padrões. Apenas deixe claro o que é esperado. Exemplo: symfony.com/doc/current/contributing/code/patches.html Role para a Etapa 3: Envie seu patch

— Cerad 26/14/14

@ Granko: "Rebase" e "rebase em um único commit" são dois problemas separados.

— Matthew Scharley

Se um colaborador for solicitado a fazer isso, ele deve substituir a ramificação da solicitação de recebimento git push -f?

— Flimm

No que diz respeito ao Git, é uma espécie de guerra santa se você deve simplesmente mesclar ramificações ou refazer as confirmações na versão mais recente da ramificação na qual está se fundindo. Há muitas conversas sobre o que é melhor se você fizer uma pesquisa rápida no Programmers.SE .

Quanto à etiqueta por trás disso, vamos lidar com isso de uma perspectiva prática. Ao lidar com o novo código vindo de outra pessoa, é sempre melhor fazer com que ela mescle as alterações mais recentes da ramificação ou refazê-las novamente antes de mesclar para garantir uma mesclagem limpa. Lembre-se de que eles escreveram o código e, portanto, são de longe os mais qualificados para lidar com qualquer conflito de mesclagem / rebase. Pessoalmente, não vejo problemas com isso e vejo esse pedido o tempo todo de outras pessoas. Para mim, se não houver conflitos, geralmente eu mesmo faço isso já que é uma atualização de dois segundos que o git pode se aplicar. Mas se houver conflitos, sempre solicitarei ao autor original do código que lide com eles mesmos.

Além disso, especificamente para o GitHub (no mínimo), eles exibirão um link para seu CONTRIBUTINGarquivo acima de qualquer tentativa de relações públicas, de modo que seja um bom local para delinear suas expectativas e muitos projetos incluem que eles apenas se unirão às ramificações atualizadas.

— Matthew Scharley
fonte

+1 por trazer pragmatismo para a discussão. Sim, esse é o objetivo. Pode ser bastante difícil resolver conflitos complexos em grandes solicitações de recebimento, especialmente quando um certo número de confirmações está envolvido. É nesse ponto que o autor original deve ser convidado a participar. Os conflitos fáceis não são o problema, eles nunca foram e nunca serão.

— JensG

+1 por realmente fornecer uma resposta e não apenas comentários!

— Pablojim