A tendência do ramo "develop" indo embora

Ele vem da mentalidade 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, já que sentimos que ele não oferecia nenhum benefício adicional, mas algumas desvantagens. Nós configuramos nosso software de CI (Teamcity) para compensar as desvantagens:

1. Habilite a implantação de um commit específico. Em outras palavras: não implantamos um ramo. Nós implantamos um commit.
2. Podemos implantar o mestre ou as ramificações começando com um hotfix / prefixo.

A razão pela qual isso funciona é porque todos os pedidos pull contêm códigos potencialmente liberáveis, mas isso não significa que implantamos todos os commits no master.

A principal razão pela qual abandonamos o ramo de desenvolvimento é porque ele costumava ficar muito grande e consumir muito tempo para ver o que realmente continha. Se tivermos implantado algo um pouco prematuramente, apenas desdobramos uma ramificação de hotfix e implantamos isso diretamente.

Um ramo de desenvolvimento é mais importante se o seu processo de lançamento for complexo e você precisar de candidatos sérios.

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

Nesse caso, pode fazer mais sentido isolar um "release candidate" em um branch não mestre (como "develop"). Isso permite que sua equipe que executa esses testes tenha uma ramificação para mesclar recursos.

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

No entanto, observe que:

• Muitos (a maioria?) projetos no github não têm esse tipo de restrição
• Um "mestre" principal tem o mesmo objetivo
• Um fluxo de trabalho de "fazer um PR vs mestre" é muito mais universal do que "fazer um PR contra um ramo que você não conhece imediatamente neste repositório"

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

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

2. Desenvolva em 'master' e tenha uma ramificação de nome diferente para versões de produção estáveis. Isso faz ainda mais sentido se o seu projeto tiver vários ramos de liberação de cada vez (por exemplo, o preferido atual é o Release-1.8, mas você também ainda mantém o Release-1.7).

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

Lançamentos para produção podem ser marcados, então a situação que foi lançada sempre pode ser reproduzida sem dedicar um ramo inteiro para este propósito.

Se um bug crítico é encontrado na produção em um momento em que o master não pode ser liberado, então é fácil verificar a tag e iniciar uma nova ramificação "hotfixes-for-release-1.2.0" a partir daí. Mas isso deve ser bastante raro.

Na maior parte do tempo, em nossos aplicativos da web, o mestre mudou desde o último lançamento, mas não de forma muito significativa, portanto, podemos simplesmente fazer um novo lançamento do mestre que tenha a correção. Ajuda mesmo a fazer lançamentos muito frequentes.

If developers are working on feature branches, and then merging those into master when they're done, that means there's a period of time where features/fixes are being merged into master and the master branch is actually newer than production.

...

Imagine if people are merging straight into master, and a bug is reported in production that becomes difficult to fix because the master branch codebase has changed significantly.

Isso não é o fluxo do Github.

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

Deploy

Once your pull request has been reviewed and the branch passes your tests, you can deploy your changes to verify them in production. If your branch causes issues, you can roll it back by deploying the existing master into production.

Merge

Now that your changes have been verified in production, it is time to merge your code into the master branch.

(ênfase minha)

Em outras palavras, master nunca estará à frente da produção. Da mesma forma, master estará sempre em um estado estável e liberável (além de bugs não descobertos), já que tudo é revisado, testado e lançado para produção anterior sendo mesclado para master .

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

É preciso haver uma maneira de testar vários recursos, mesclar vários recursos e implantá-los. Eu tenho usado uma 'ramificação de pacote' (uma ramificação criada a partir do mestre com ramos de recurso prontos para teste mesclados nela) que é implantada em qa / uat. As correções durante o uso ocorrem apenas no ramo de recursos, e essas são novamente mescladas no ramo do pacote. Depois que uma subseção do ramo de bundles for aprovada, somente os recursos aprovados no bundle receberão pull-requested para masterizar - e o ciclo será contínuo.

Eu uso isso com o Gitflow, mas pensando em usá-lo para o fluxo do GitHub. O QA / UAT muitos recurso em uma questão de tempo parece de importância. Outro problema com o fluxo do GitHub é que ele assume todos os desenvolvedores sr, e isso nem sempre é o caso.

Eu prefiro usar o fluxo do GitHub devido à sua simplificação. Com um recurso semelhante a um pacote, acho que seria melhor prepará-lo. É possível que o pacote seja semelhante ao release; no entanto, eu ainda estou ponderando isso também.

Outro problema é que o processo de solicitação de extração acontece no final antes de mesclar ao mestre; no entanto, às vezes, você deseja revisar o código antes do teste de qa comercial - por isso, bem antes da mesclagem