Git - Quais problemas surgem do trabalho direto no mestre?

Eu já vi muitos conselhos sobre modelos de ramificação git e a opinião mais comum parece ser que fazer alterações diretamente no ramo mestre é uma má ideia.

Um de nossos colegas de trabalho está muito feliz em fazer alterações diretamente no ramo principal e, apesar de várias conversas, parece que eles provavelmente não mudarão isso.

Neste momento, não consigo convencer um colega de trabalho que é uma prática ruim trabalhar diretamente no mestre, mas gostaria de entender as coisas que entrarão em conflito com sua maneira de trabalhar, para saber quando preciso revisitar esse assunto.

Existem vários problemas quando as confirmações são enviadas diretamente para o mestre

• Se você enviar um estado de trabalho em andamento para remoto, o mestre estará potencialmente quebrado
• Se outro desenvolvedor começar a trabalhar para um novo recurso do mestre, ele começará com um estado potencialmente interrompido. Isso diminui o desenvolvimento
• Recursos / correções diferentes não são isolados, de modo que a complexidade de todas as tarefas de desenvolvimento em andamento é combinada em um único ramo. Isso aumenta a quantidade de comunicação necessária entre todos os desenvolvedores
• Você não pode fazer solicitações pull, que são um mecanismo muito bom para revisões de código
• Você não pode espremer confirmações / alterar o histórico do git em geral, pois outros desenvolvedores já podem ter puxado o ramo mestre nesse meio tempo

Explique a ele que os novos recursos precisam de seu próprio ramo de desenvolvimento que possa ser implantado em um ambiente de teste antes de ser enviado à produção.

Caso contrário, você estará em um estado perpétuo de recursos pela metade. Você não pode implantar recursos semi-concluídos na produção; portanto, se você estiver trabalhando diretamente na ramificação mestre, todos os outros deverão esperar que você conclua seu recurso antes que as alterações de outros possam entrar em produção, incluindo correções.

O uso de ramificações independentes para recursos significa que cada novo recurso pode ser testado e implantado independentemente dos outros.

O mestre deve ser potencialmente liberável. Período. Não deve haver trabalho pela metade no mestre (a menos que esteja desativado com um sinalizador de recurso)

Com isso dito, eu vi algumas equipes complicarem seu fluxo.

Não usar o PR ao integrar ao mestre é um erro, pois os desenvolvedores não terão o poder de escolher quando a integração ocorrer.

Um único ramo de desenvolvimento traz muito pouco valor. Geralmente isso apenas complica as coisas. Muitos ramos de recursos traz muito valor.

Criar ramificações para cada ambiente (dev, test, prod) é um erro. Isso está fora do escopo do git e deve ser tratado pelo pipeline de lançamento. A mesma construção exata deve ser implantada em todos os ambientes, o que é impossível se houver ramificações para cada ambiente.

Se um recurso é tão grande que não pode ser feito em um ou dois dias, todo o trabalho em um ramo de recurso deve estar em ramos separados e integrado ao PR.

• O mestre deve refletir um ramo de produção, uma versão final de trabalho.
• Trabalhar diretamente no mestre significa que, se você criar bugs, não terá outra opção para "voltar" do que reverter / excluir / redefinir confirmações, o que não é uma maneira limpa de trabalhar e pode causar a perda de partes do novo código que estavam bem.
• É claro que, nos primeiros estágios do desenvolvimento, talvez você possa começar a trabalhar diretamente no mestre, mas depois de ter algo a oferecer, use ramos de desenvolvimento, teste ou experiência para não tocar na versão de trabalho publicada, completa e em execução.

Primeiro, quero salientar que no git, tudo pullé literalmente uma operação de ramificação e tudo pushé uma mesclagem. A mastermáquina on de um desenvolvedor é uma ramificação completamente separada da masterem um repositório central que você compartilha, com a mesma posição de uma perspectiva técnica. Ocasionalmente, vou renomear minha versão local upstreamou algo assim, se ela se adequar melhor aos meus propósitos.

Aponto isso porque muitas organizações pensam que estão usando filiais com mais eficiência do que o seu colega, quando na verdade estão fazendo pouco mais do que criar um nome adicional para uma filial ao longo do caminho, que não será salva na história. Se o seu colega está confirmando recursos em uma confirmação atômica, é tão fácil voltar como uma confirmação de mesclagem de uma ramificação de recursos. A grande maioria dos ramos de recursos deve ter uma vida útil muito curta e, freqüentemente, mesclada de qualquer maneira.

Dito isto, os principais inconvenientes de seu estilo de trabalho são duplos. Primeiro, torna muito difícil colaborar em um recurso inacabado. No entanto, não seria difícil criar uma filial apenas nos momentos em que a colaboração é necessária.

Segundo, torna a revisão antes da mesclagem muito difícil. Nesse ponto, você não precisa convencê-lo. Você pode adotar uma ferramenta como github, gerrit ou gitlab e exigir revisões de código de solicitação pull e passou por testes automatizados para todas as mesclagens. Se você não está fazendo algo assim, francamente, você não está usando o git em todo o seu potencial, e não é de admirar que seu colega não veja esse potencial.

Outras respostas já mencionaram várias vantagens (recursos isolados, código sempre entregável no mestre, etc.) por trabalhar NÃO no mestre diretamente.

Para mim, você parece ter um problema diferente. Obviamente, você não possui um processo de desenvolvimento, que é acordado ou usado por todos os seus desenvolvedores (ou o desenvolvedor em questão está ignorando totalmente o processo).

Você possui ramificações de recursos, que são mescladas no master ou também possui ramificações de versões diferentes ou utiliza um processo totalmente diferente?

"Não use o ramo mestre" não é suficiente.

Um de nossos colegas de trabalho está muito feliz em fazer alterações diretamente no ramo principal e, apesar de várias conversas, parece que eles provavelmente não mudarão isso.

Isso me leva a acreditar que há mais problemas. Trabalhar no master ou não faz parte principalmente de uma filosofia maior sobre como, o que e quando você lança produtos.

Portanto, em conjunto com um "você nunca deve trabalhar no mestre", você tem testes de recursos, você testa o trabalho um do outro, revisa o código um do outro. Testes de aceitação e integração.

Se você não tem nenhuma das opções acima e está apenas fazendo isso para "fazer git", você também pode trabalhar no master.

Não há "má prática" em trabalhar diretamente na filial. Mas você precisa decidir o que melhor suporta seu processo:

Pergunta 1: Seu mestre deve representar o estado atual da versão do seu software? Em seguida, você deve apresentar um ramo de desenvolvimento global e mesclar o desenvolvimento no final de um desenvolvimento de release.

Pergunta 2: você deseja ter um processo de revisão de código? Então você deve ter "ramificações de recursos" que serão mescladas no mestre (ou no desenvolvimento, se você tiver um) por meio de solicitações pull.

Pergunta 3: É necessário compartilhar o estado do código intermediário com outros desenvolvedores que ainda não devem ser publicados na produção (ou teste)? É o caso de mais de um desenvolvedor desenvolver um recurso. Então você deve introduzir "ramos de recursos".