Lidando com uma solicitação pull grande

Atualmente, estou trabalhando em um projeto com uma equipe que usa um fluxo de trabalho git. É bastante simples, o mestre deve estar em um estado implementável e as ramificações são usadas para criar recursos e hotfixes. Sempre que tivermos um recurso ou correção de bug concluído e testado, passamos a dominar o mais rápido possível. A idéia é que os ramos sejam o menor possível para facilitar a mesclagem deles de volta ao mestre. Temos uma política de que qualquer código enviado para a ramificação principal deve estar em um estado implementável e ser aprovado nos testes.

Temos uma situação em que um dos desenvolvedores fez muito trabalho (alguns meses no valor) em uma única ramificação e essa ramificação ainda não foi incorporada ao master. Agora, existem alguns recursos separados e muitos commits nesse ramo, essencialmente esse ramo já deveria ter sido mesclado algumas vezes, mas até agora não foi. A maior parte do código está em bom estado com testes de unidade que podem ser mesclados novamente no mestre, mas as alterações mais recentes certamente não devem ocorrer, pois não são concluídas e não são testadas.

Qual é a melhor maneira de lidar com uma situação em que um ramo está muito longe dos outros? De que maneiras podemos evitar que as filiais obtenham um número muito grande de confirmações do master no futuro?

Deixe o desenvolvedor que passou alguns meses sem mesclar corrigi-lo. Talvez eles possam obter um grande pedaço de código para mesclar, talvez eles possam ter um monte de pequenos pedaços para mesclar um de cada vez. De qualquer forma, eles deveriam fazer o trabalho braçal para resolver o problema, já que o causaram.

Qual é a melhor maneira de lidar com uma situação em que um ramo está muito longe dos outros?

Em geral, não se preocupe: o problema é do outro desenvolvedor. Se dois ramos são realmente muito longe de junção, então eles não são realmente parte do mesmo projeto mais e você tem um garfo defacto. Se é um projeto de código aberto, isso pode até não ser um problema.

Se esse desenvolvedor é realmente brilhante e seu código é melhor / mais inteligente / mais importante do que o resto da equipe combinada, vale a pena torná-lo seu problema e não o deles. Caso contrário, não é.

Para responder à pergunta literal: a melhor maneira de lidar com esse tipo de situação é não entrar nesse tipo de situação.

De que maneiras podemos evitar que as filiais obtenham um número muito grande de confirmações do master no futuro?

Certifique-se de que todos percebam que o desenvolvedor que passou meses sem se unir está precisando corrigir o problema que causou. Certifique-se de que todos saibam que é mais fácil se comprometer a dominar com frequência do que com pouca frequência, pois menos alterações significam menos oportunidades de conflitos.

Certifique-se de que as pessoas saibam que podem usar o mestre para se manterem atualizadas com as mudanças de outras pessoas.

"Se você se fundir todos os dias, de repente você nunca chega ao ponto de ter enormes conflitos difíceis de resolver". --Linus Torvalds

Essa citação é de uma palestra que ele fez no Google, aqui está a transcrição , e aqui está o vídeo .

Se você tem uma confirmação que você sabe disso e todas as confirmações anteriores são bem testadas e devem ser mescladas, basta ramificar a partir desta última confirmação válida e mesclar a nova ramificação com o mestre.

Se você tem alguns commits que gostaria de mesclar, mas eles são intercalados com outros commits que não estão prontos para produção, então eu vejo duas possibilidades:

1. Crie uma nova ramificação, e a cereja escolhe boas confirmações, mescla-se com o mestre.
2. Tente refazer as confirmações indesejadas para o topo (talvez em uma nova ramificação apenas por segurança).

Quanto aos métodos de prevenção, tente definir algumas regras engraçadas da equipe, como "Uma que não se mescla com o mestre dentro de uma semana pedirá pizza por um mês".

Primeiro, veja se realmente existem confirmações separadas que podem ser mescladas ou escolhidas com cereja, como sugerido por @Maciej Chalpuk. Se for esse o caso, a situação realmente não é tão ruim e não me preocuparia muito com isso no futuro.

No entanto, se a situação real é que vários recursos foram desenvolvidos simultaneamente em uma única ramificação, dentro dos mesmos commits, torna-se muito mais difícil de lidar. Felizmente, o método de prevenção está embutido: exija que o desenvolvedor separe as alterações de cada recurso em ramificações separadas e solicite antes de mesclá-las. Você obterá suas mesclagens atômicas e dissuadirá esse desenvolvedor de fazê-lo o futuro.

O processo real de separar os recursos é totalmente manual. Crie novas ramificações fora do mestre e copie as alterações do mega ramo que estão relacionadas a ela. Compile, teste o recurso, envie e envie uma solicitação de recebimento. Quanto menos misturadas as alterações de código, mais fácil será fazer. Se ele estava hackeando um único método para todos eles, divirta-se. Ele não fará isso de novo.

Aqui está uma solução simples.

Acompanhe os recursos que essa pessoa implementou e vá para cada confirmação nesse ramo que foi atualizado por recurso. Aceite esse commit e mescle-o com o repositório principal.

Deixe-me explicar isso na forma de um exemplo.

Seja: Ramo A o ramo do mestre Ramo A + = Ramo A + novo recurso 1 Ramo A ++ = Ramo A + novo recurso 2 e assim por diante

O que você precisa fazer é voltar para: Filial A +

Pegue a ramificação A + e mescle-a com o mestre.

Agora vá para o Branch A ++ e mescle-o com (Master + Branch A +).

Repita até chegar ao ramo A + ... + final estável.

Esse método pode parecer contra-intuitivo no início, mas se você mesclar cada novo recurso separado por conta própria com o mestre, fica fácil alternar entre a ramificação mestre " por recurso adicionado "

De que maneiras podemos evitar que as filiais obtenham um número muito grande de confirmações do master no futuro?

Acho que minha solução acima indica qual método futuro você deve adotar. Escolha um método por recurso ou por tarefa para cada ramificação.

Eu sugeriria usar uma abordagem de:

pré-mestre e mestre

master: Final / nível de produção. É modificado não frequentemente. É considerado sempre estável

pré-mestre: a área em que um novo recurso é adicionado ao código existente. É testado minuciosamente para trabalhar com a base de código existente e é o local onde outras ramificações podem se ramificar para a implementação de novos recursos.

Você também deve tentar agrupar recursos e ter como objetivo a segmentação por versão.

Destino da versão: especifique um número arbitrário que atuará como o espaço reservado para a ramificação principal. "Na V1.0.0, queremos obter os recursos X, Y, Z. A V1.0.0 também terá todas essas funcionalidades disponíveis: ..."

Ao manter uma versão em relação ao mestre, também pode ser uma maneira de manter o "mestre" estável e pronto para produção em todos os momentos.

Corrigir o problema da solicitação pull grande é uma coisa, e há algumas boas respostas sobre isso. Mas, ao lidar com filiais que estão muito desatualizadas, convém revisitar seus processos para lidar com o trabalho em equipe.

Se você estiver trabalhando em uma estrutura Agile ou SCRUM, a equipe deve realmente perguntar por que o recurso não foi concluído e mesclado como parte da iteração / sprint. Se era "grande demais" para caber em uma iteração, deveria ter sido dividido em partes menores.

Isso também levanta uma questão de propriedade do código - dentro da sua equipe, os desenvolvedores individuais possuem seu próprio trabalho separadamente ou a equipe completa trabalha em conjunto para garantir que os itens sejam concluídos?

Obviamente, o exposto acima pressupõe que sua equipe esteja dentro de algum tipo de estrutura da empresa. Se este é um projeto de código aberto com colaboradores voluntários, isso é outra história. Geralmente, esses projetos têm um controle mais fraco sobre os fluxos de trabalho, mas o ônus de gerar solicitações de recebimento aceitáveis ​​recai com mais frequência nos colaboradores individuais.

De muitas maneiras, isso se torna uma questão de processo. Talvez o processo necessário inclua a verificação periódica (semanal? Mensal?) De ramificações imersas e de execução longa. Algumas ferramentas simplificam a verificação visual; por exemplo, no github, visite o link "branches" e mostra o quão à frente / atrás de cada branch está.