É uma boa idéia exigir a confirmação apenas do código ativo?
Esta confirmação não precisa deixar o repositório em um estado de trabalho como:
- ... estamos nos estágios iniciais do projeto, o código ainda não é estável.
- ... você é o único desenvolvedor do projeto. Você sabe por que as coisas não estão funcionando. Além disso, você não está parando o trabalho de ninguém, comprometendo o código quebrado.
- ... o código atualmente não funciona. Nós vamos fazer uma grande mudança. Vamos nos comprometer, a fim de ter um ponto para reverter se as coisas ficarem feias.
... a cadeia é longa, não há problema se houver código quebrado na ramificação local. Ou seja,
- ficheiros locais
- área de preparação
- confirma no ramo local
- confirma no ramo remoto de recursos pessoais
- mesclar com
develop
ramificação remota - mesclar com
master
ramificação remota - mesclar com
release
ramificação remota
... comprometer-se cedo, comprometer-se frequentemente.
Portanto, na pergunta acima vinculada, a maioria das respostas diz que a confirmação de código não compilável não é problema nas ramificações locais e de recursos. Por quê? Qual é o valor de um commit quebrado?
Adicionado: Existem alguns comentários altamente votados, dizendo que em um brach local pode-se fazer o que quiser. No entanto, não estou interessado no lado técnico da questão. Em vez disso, gostaria de aprender as melhores práticas - os hábitos, que as pessoas que trabalham muitos anos na indústria, têm mais produtivo.
Estou impressionado com a vasta quantidade de ótimas respostas! Eles me levaram à conclusão de que não sou adepto do uso de ramificações para organizar meu código.