A tendência do ramo “desenvolver” desaparecendo

82

Ultimamente, notei algo olhando alguns projetos populares no GitHub, que não há developramificação. E, de fato, o guia GitHub Flow também não o menciona. Pelo meu entendimento, mastersempre deve ser totalmente estável e refletir a produção. Se os desenvolvedores estiverem trabalhando em ramificações de recursos e depois mesclando-os masterquando terminar, isso significa que há um período em que os recursos / correções estão sendo mesclados mastere a masterramificação é realmente mais recente que a produção.

Não faria mais sentido que a equipe crie ramificações de recursos / correções develop, junte -se a elas e, quando a próxima versão estiver totalmente pronta para o lançamento, developfor mesclada mastere uma tag for criada? Imagine se as pessoas estão se unindo diretamente mastere um bug é relatado na produção que se torna difícil de corrigir porque a masterbase de código do ramo mudou significativamente. Em seguida, os desenvolvedores precisam dizer ao usuário que aguarde até a próxima versão para ver o problema resolvido.

Edição: Esta pergunta é diferente de "para ramificar ou não ramificar". Ele aborda especificamente as pessoas que deixam de usar o ramo de desenvolvimento e as razões que o cercam, uma vez que isso foi apontado como uma prática recomendada por um longo tempo.

ffxsam
fonte
11
Existem muitos fluxos de trabalho possíveis que o git permite. Não se deve esperar que o gitflow ou o github seja usado em todos os projetos.
Pergunta muito interessante. Eu trabalhei anos com o nvie.com/posts/a-successful-git-branching-model e tenho que dizer que gosto. O que eu mais gosto é que: a) mestre é o que está em produção e aplica-se também às versões eb) há uma clara diferença entre um hotfix e um recurso, eles são iniciados e mesclados no mestre e desenvolvidos respectivamente. No entanto, depois de seguir essa discussão, começo a duvidar se é algo que complica demais. Alguma opinião sobre isso?
Aspasia
1
Eu odeio o conceito de que mestre é um registro do que está em produção. Se precisarmos saber o que está em produção, devemos apenas consultar a produção e não confiar no mestre que reflete com precisão o que está em produção.
Jim V

Respostas:

52

Vem da mentalidade do IC, onde há integração várias vezes ao dia.

Existem prós e contras de ambos.

Em nossa equipe, também abandonamos o ramo de desenvolvimento, pois sentimos que ele não oferecia nenhum benefício adicional, mas algumas desvantagens. Configuramos nosso software de CI (Teamcity) para compensar os inconvenientes:

  1. Habilite a implantação de uma confirmação específica. Em outras palavras: não implantamos uma filial. Implementamos uma confirmação.
  2. Podemos implantar mestre ou ramificações, começando com um hotfix / prefixo.

O motivo disso funcionar é porque todas as solicitações pull contêm código potencialmente liberável, mas isso não significa que implantaremos todas as confirmações no mestre.

A principal razão pela qual abandonamos o ramo de desenvolvimento é porque ele tendia a ficar muito grande e consumir muito tempo para ver o que realmente continha. Se implantamos algo um pouco prematuramente, apenas ramificamos um ramo de hotfix e o implantamos diretamente.

Esben Skov Pedersen
fonte
11
Tendo trabalhado com um ramo desenvolver para um ano ou dois, apenas para tê-lo incorporado mestre de vez em quando, eu só posso dizer: Amém, abandonar aquela coisa:]
stijn
Interessante. Então, suponho que, quando você lança a versão 1.3, por exemplo, você marca um commit específico master; assim, se um bug surgir mais tarde enquanto masterestiver em um estado de fluxo, poderá facilmente ramificar um hotfix da marca 1.3?
Ffxsam 7/03/16
5
Eu diria que o benefício de "desenvolver" depende muito do tipo de software que você está criando, como é implantado e se precisa oferecer suporte a várias versões ao vivo ou não.
axl
1
@ffxsam, nem precisamos de tags, porque estamos rastreando qual ID de git está atualmente implementado. Isso é registrado no TeamCity e ramificado nas dlls implantadas e no portal de gerenciamento do azure. Portanto, não sentimos a necessidade de mais marcação, exceto a marcação automática feita pelo TeamCity. Se você acha que a marcação se encaixa melhor no seu fluxo de trabalho, isso também resolveria bem. Mas sim, em princípio, ramifique diretamente da alteração atualmente implantada para criar uma ramificação de hotfix.
Esben Skov Pedersen
25

Uma ramificação de desenvolvimento é mais importante se o seu processo de lançamento for complexo e você precisar de candidatos a lançamento sérios.

Por exemplo, imagine que você está escrevendo um software que é firmware para carros. Isso é ... não-trivial de corrigir e é provável que qualquer versão tenha um conjunto abrangente de testes que não sejam de CI / integração executados em hardware real.

Nesse caso, pode fazer mais sentido isolar um "candidato à liberação" em uma ramificação não principal (como "desenvolver"). Isso permite que sua equipe que executa esses testes tenha uma ramificação na qual mesclar recursos.

Webapps ou outro software facilmente atualizado não tem essa restrição.

No entanto, observe que:

  • Muitos projetos (a maioria?) No github não têm esse tipo de restrição
  • Um "mestre" principal serve ao mesmo propósito
  • Um fluxo de trabalho de "criar um PR versus mestre" é muito mais universal do que "criar um PR em um ramo que você não conhece imediatamente neste repositório"
enderland
fonte
18

Existem duas filosofias que eu já vi em projetos, e acho que a escolha é apenas uma questão de gosto:

  1. Designe 'mestre' como o release de produção e desenvolva em um ramo 'desenvolva'.

  2. Desenvolva em 'master' e tenha uma ramificação de nome diferente para lançamentos de produção estáveis. Isso faz ainda mais sentido se o seu projeto tiver várias ramificações de versão por vez (por exemplo, a atual preferida é a Versão 1.8, mas você também ainda mantém a Versão 1.7).

Ambas são abordagens comuns e têm seus prós e contras.

Larry Gritz
fonte
Eu concordo com você. Preferimos ter ramificações de lançamento e mantê-las até o próximo lançamento de produção. Se tivermos de fazer quaisquer-hot fixes, nós o checkout da última ramo release e trabalhar em que, em seguida, mesclar essas hot-fixes em master / desenvolver ramo
Johnny
Exatamente. O que o 'mestre' deve fazer é principalmente semântica. O fundamental para acertar é evitar a necessidade de manter vários ramos eternamente sincronizados bidirecionalmente, a menos que você tenha realmente um bom motivo para fazê-lo. A ramificação 'master' no Git Flow é apenas uma réplica atrasada de 'develop', portanto não conta realmente. O antipadrão está permitindo que o principal ramo de desenvolvimento mantenha alterações que nunca entram em um lançamento, o que é uma prática chocante que eu já vi. Os dois modelos mencionados acima evitam isso, e é por isso que eles funcionam.
John Michelau 26/03
7

As liberações para produção podem ser marcadas, para que a situação lançada sempre possa ser reproduzida sem dedicar um ramo inteiro para essa finalidade.

Se um bug crítico for encontrado na produção no momento em que o mestre não puder ser liberado, será fácil verificar a tag e iniciar um novo ramo "hotfixes-for-release-1.2.0" a partir daí. Mas isso deve ser bastante raro.

Na maioria das vezes, em nossos aplicativos da Web, o master mudou desde a última versão, mas não de maneira muito significativa, para que possamos simplesmente fazer uma nova versão do master que tenha a correção. Ajuda a fazer lançamentos muito frequentes de qualquer maneira.

RemcoGerlich
fonte
5

Se os desenvolvedores estiverem trabalhando em ramificações de recursos e depois mesclando-os no master quando terminar, isso significa que há um período em que os recursos / correções estão sendo mesclados mastere a masterramificação é realmente mais recente que a produção.

...

Imagine se as pessoas estão se unindo diretamente ao mestre e é relatado um erro na produção que se torna difícil de corrigir porque a base de código do ramo principal mudou significativamente.

Esse não é o Github Flow.

Este é o processo de implantação / mesclagem do Github Flow, de acordo com o seu link:

Implantar

Depois que sua solicitação de recebimento for revisada e a ramificação passar em seus testes, você poderá implantar suas alterações para verificá-las em produção. Se sua ramificação causar problemas, você poderá recuperá-la implantando o mestre existente na produção.

Mesclar

Agora que suas alterações foram verificadas na produção, é hora de mesclar seu código na ramificação principal.

(Ênfase minha)

Em outras palavras, masternunca estará à frente da produção. Da mesma forma, mastersempre estará em um estado estável e liberável (além de bugs não descobertos), pois tudo é revisado, testado e implementado na produção antes de ser mesclado master.

8bittree
fonte
Agradável! Isso faz muito sentido intuitivo - masteré sempre a sua posição de reversão se o ramo de recursos que você coloca na produção falhar. Caso contrário, ele será mesclado mastere se tornará o novo substituto. Eu gosto disso.
Bill Horvath
1

O problema que vejo é que a implantação / mesclagem de fluxo do Git / Hub assume que um recurso está sendo desenvolvido / testado / mesclado / implantado por vez - e, na minha experiência, esse não é o caso. Se mesclamos um recurso de cada vez, há uma chance maior de problemas de regressão - encontrados somente depois que os recursos são mesclados para mestre e possivelmente em produção.

É preciso haver uma maneira de testar vários recursos, mesclar vários recursos e implantar o mesmo. Estou usando um 'ramo de bundle' (um ramo criado a partir do mestre com os ramos de recursos prontos para teste mesclados a ele) que é implantado no qa / uat. As correções durante o uat acontecem apenas na ramificação do recurso, e essas são mescladas novamente à ramificação do pacote. Após a aprovação de uma subseção da ramificação do pacote configurável, somente os recursos aprovados no pacote configurável são solicitados por solicitação de masterização - e o ciclo é contínuo.

Eu uso isso com o Gitflow, mas pensando em usá-lo para o fluxo do GitHub. O recurso QA / UAT muitos de cada vez parece significativo. Outro problema no fluxo do GitHub é que ele assume todos os desenvolvedores sr, e esse nem sempre é o caso.

Prefiro usar o fluxo do GitHub devido à sua simplificação. Com um pacote como recurso, acho que estaria melhor preparado. É possível que o pacote seja semelhante ao lançamento; no entanto, ainda estou pensando nisso.

Outro problema é o processo de solicitação de recebimento que ocorre no final antes da mesclagem com o mestre; no entanto, às vezes você deseja codificar a revisão antes do teste de qa comercial - portanto, muito antes da mesclagem

David Latty
fonte