É sempre correto comprometer código não funcional?

35

Is it good idea to require to commit only working code?

Este commit não precisa deixar o repositório em um estado de funcionamento como:

  • ... estamos nos primeiros estágios de design, o código ainda não está estável.
  • ... você é o único desenvolvedor do projeto. Você sabe porque 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 nisso. Vamos nos comprometer, a fim de ter um ponto a ser revertido se as coisas ficarem feias.
  • ... a cadeia é longa, sem problemas se o código quebrado existir no ramo local. Ou seja,

    1. arquivos locais
    2. área de preparação
    3. confirma na filial local
    4. confirma na ramificação do recurso pessoal remoto
    5. mesclar com o remoto develop branch
    6. mesclar com o remoto master branch
    7. mesclar com o remoto release branch
  • ... comprometer-se cedo, comprometer-se com frequência.

Portanto, na pergunta acima, a maioria das respostas diz que cometer código não compilável não é problema em ramificações locais e de recursos. Por quê? Qual é o valor de um commit quebrado?

Adicionado: Há um par de comentários altamente votados, dizendo que em um brach local pode-se fazer o que se quer. No entanto, não estou interessado no lado técnico da questão. Em vez disso, eu gostaria de aprender as melhores práticas - os hábitos, que as pessoas que trabalharam muitos anos na indústria, são mais produtivas.

Estou espantado com a grande quantidade de ótimas respostas! Eles me levam à conclusão de que eu não sou adepto o suficiente para usar branches para organizar meu código.

    
por Vorac 16.09.2013 / 11:29
fonte

11 respostas

18

Uma das filosofias de ramificação (seção Desenvolvimento da estratégia de ramificação e política de codificação em Estratégias avançadas de ramificação do SCM - leia também Perforce Best practices , é um pdf, mas entra em alguns outros detalhes) é que você se ramifica na política incompatabile.

A codeline policy specifies the fair use and permissible check-ins for the codeline, and is the essential user’s manual for codeline SCM. For example, the policy of a development codeline should state that it isn’t for release; likewise, the policy of a release codeline should limit changes to approved bug fixes. The policy can also describe how to document changes being checked in, what review is needed, what testing is required, and the expectations of codeline stability after check-ins. A policy is a critical component for a documented, enforceable software development process, and a codeline without a policy, from an SCM point of view, is out of control.

(de práticas recomendadas do Perforce)

Digamos que você tenha as ramificações 'release' (ou 'master') a partir das quais uma versão é criada e 'trunk' (ou 'dev') onde os desenvolvedores verificam o código de trabalho. Estas são as políticas dos ramos. Observando que o 'código de trabalho' é parte da política de ramificação 'dev', nunca se deve cometer um código quebrado para a ramificação dev. Freqüentemente, há coisas como os servidores de CI conectados a essas ramificações e a verificação de código quebrado no dev pode atrapalhar o branch de todos e interromper a compilação.

No entanto, há momentos em que é apropriado verificar o código parcial que não funciona. Nestes casos, deve-se ramificar - uma política incompatível com o tronco. Nesta nova ramificação, pode-se decidir a política ('código quebrado está ok') e depois cometer o código para ela.

There is one simple rule to determine if a codeline should be branched: it should be branched when its users need different check-in policies. For example, a product release group may need a check-in policy that enforces rigorous testing, whereas a development team may need a policy that allows frequent check-ins of partially tested changes. This policy divergence calls for a codeline branch. When one development group doesn’t wish to see another

(de práticas recomendadas do Perforce)

Perceba que isso vem de um SCM baseado em servidor central com uma strong mentalidade corporativa. A ideia principal ainda é boa. Estes são frequentemente considerados implicitamente - você não verifica o código dev não testado na ramificação do release. Isso é uma política.

Então, ramifique-se, diga que esse ramo pode ter código quebrado e se comprometer.

    
por 16.09.2013 / 17:00
fonte
37

Uma das filosofias sugeridas por Linus Torvalds é que a programação criativa deve ser como uma série de experimentos. Você tem uma ideia e segue-a. Nem sempre funciona, mas pelo menos você tentou. Você quer incentivar os desenvolvedores a tentar ideias criativas, e para fazer isso, deve ser barato experimentar esse experimento, e barato para se recuperar. Este é o verdadeiro poder do git compromete-se a ser tão barato (rápido e fácil). Ele abre esse paradigma criativo que capacita os desenvolvedores a experimentar coisas que eles não teriam de outra forma. Esta é a libertação do git.

    
por 16.09.2013 / 13:30
fonte
10

Sim, desde que não seja um ramo de lançamento.

Nas ramificações pessoais, tudo acontece e pode ser descartado se a experiência não funcionar. Esse é um dos principais benefícios do DVCS: freedom

O valor de confirmar código quebrado ?: colaboração e experimentação

    
por 16.09.2013 / 23:53
fonte
5

Sim, está tudo bem e é algo que eu faço muito.

O ponto de se comprometer com código não compilável (em filiais pelo menos) é que às vezes seu código é um trabalho em progresso, mas que o trabalho feito até agora vale a pena salvar e / ou compartilhar com outros

Minhas práticas são:

  • escrever testes primeiro
  • wip (work-in-progress) commits são bons
  • confirmar com frequência (vários em um dia) e início (salvar etapas de 'trabalho')
  • empurre após cada confirmação (no caso de seus discos rígidos travarem / o barramento atingir você)
  • sempre trabalha primeiro nas filiais
  • quando possível, apenas mescle no código de trabalho para dominar
  • rebase interativa em git to squash wips antes da mesclagem de mestre

A questão principal e talvez a que você está tocando é quando você tem um recurso que basicamente funciona e é extremamente necessário para o negócio (e, portanto, precisa estar em 'master'), mas tem alguns testes com falha. Uma opção aqui pode ser fazer um teste pendente que permita avançar por enquanto. No entanto, isso é repleto de perigos, pois o teste pode nunca ser corrigido e pode definir um padrão em outras áreas de testes interrompidos simplesmente em vez de corrigi-los.

Outra opção seria usar temporariamente e implantar o ramo. Isso pode ajudar em certas situações, mas geralmente não é recomendado e não é sustentável.

Talvez a melhor opção seja basicamente adotar uma abordagem mais profissional para o desenvolvimento de software e realmente exigir testes de trabalho para qualquer código comprometido. Esta é frequentemente a parte "difícil" do desenvolvimento de software, não a codificação que muitas pessoas imaginam. Uma melhor abordagem provavelmente exigirá melhores estimativas iniciais, alocação de recursos, definição de prioridades, etc. além de, durante o desenvolvimento do Agile, permitir tempo suficiente e usar disciplina suficiente para corrigir quaisquer problemas, tanto no momento em que ocorrem quanto durante sessões de apontamentos. p>

Foco no que 'feito' significa - significa que o código E os testes foram escritos, foram refatorados e funcionam. Se você ouvir comentários como "quase pronto, só precisa escrever / consertar / refatorar testes, então NÃO é feito. Dizer que um recurso é feito sem estar tecnicamente completo é um dos erros mais comuns dos programadores juniores.

    
por 16.09.2013 / 13:56
fonte
3

O valor de qualquer commit, quebrado ou não, é que o código é enviado para um servidor. Em ambientes profissionais, esse servidor é seguro, redundante e executa backups. Se eu trabalhar o dia todo, o comprometimento é uma forma de garantir que meu código sobreviva ao que quer que aconteça à minha máquina local. Os discos rígidos morrem. Laptops são perdidos ou roubados. Os backups do servidor de repositório estarão disponíveis, mesmo se o prédio for queimado.

    
por 16.09.2013 / 11:44
fonte
3

Antes de começar a ser dogmático sobre como trabalhar com o controle de versão, vale a pena pensar em por que você está trabalhando com o controle de versão.

O compromisso com o controle de versão congela o estado do seu código para referência futura - tudo fica fora disso. Olhando para diffs e fazendo patches é só ver como o código mudou entre os snapshots. Ramificações e tags são apenas formas de organizar instantâneos. Compartilhar código com outros desenvolvedores é apenas deixá-los ver um instantâneo em particular.

Quando você deve se comprometer? Quando houver uma chance razoável, você verá o estado do seu código (ou a mensagem de confirmação explicando uma alteração) no futuro.

O Git oferece a você muita flexibilidade sobre como organizar seus instantâneos. Não há repositório central para que você possa compartilhar seu código com outros devs sem enviar seu estado para o repositório 'main'. Você pode facilmente criar, mesclar & delete branches para isolar os detalhes de um conjunto de estados da narrativa do código principal. Você pode se comprometer localmente, para ajudá-lo a desfazer o seu desenvolvimento atual, e depois agrupar tudo em um único commit antes de empurrá-lo para os outros verem. Você pode marcar revisões específicas para encontrá-las mais tarde.

KISS . O que funciona melhor para um único desenvolvedor nos estágios iniciais de desenvolvimento de um projeto pequeno será completamente diferente do que você precisa fazer quando tiver cem desenvolvedores trabalhando em um sistema de missão crítica de uma década. Em qualquer processo de desenvolvimento de software, você deve evitar a criação desnecessária de artefatos simplesmente porque alguém lhe disse para fazê-lo.

    
por 16.09.2013 / 19:07
fonte
2

Pense nisso dessa maneira. Como desenvolvedor, uma das coisas mais prejudiciais que você pode fazer é impedir que outros desenvolvedores de sua equipe trabalhem em suas tarefas.

A filosofia de somente cometer código de trabalho vem de equipes de desenvolvimento trabalhando no mesmo tronco único no repositório. Pode parecer uma loucura agora, mas 10 anos atrás, essa era a maneira normal de trabalhar. Um ramo apareceria quando você quisesse criar uma versão estável, mas o pensamento de um desenvolvedor trabalhando em uma ramificação para implementar um novo recurso era quase inédito.

Se o seu ambiente significa que seus commits não afetam imediatamente outros desenvolvedores, então comente com frequência. ele oferece mais segurança em seu código, facilitando a reversão de um erro de código e muitos sistemas de controle de código fornecem a você alguma proteção de código para código consolidado (embora não todos).

Agora, certificando-se de que suas mesclagens com filiais compartilhadas com outros desenvolvedores funcionem, e que qualquer código que você promova para esse nível seja compilado, passe em todos os testes de unidade e outras verificações de integridade da equipe ... isso é essencial se você não usa Não quero continuar comprando a cerveja no pub ...

    
por 16.09.2013 / 17:20
fonte
2

Criar / Liberar Filiais

Você nunca deve deliberadamente enviar um código quebrado para um branch de compilação. Qualquer ramificação que esteja sob integração contínua ou a partir da qual as versões ou compilações diárias sejam feitas deve sempre estar em um estado potencialmente liberável.

Outros ramos: Salvar estado frequentemente

Para ramos particulares ou de recursos, os objetivos geralmente são diferentes. O check-in frequente do código (seja ele funcionando ou não) pode ser desejável. Geralmente, você desejará se comprometer a qualquer momento em que precisar voltar ao estado atual.

Considere estes exemplos em que o estado salvo fornece um benefício significativo:

  • Você pode executar uma confirmação antes de executar uma pesquisa e substituição globais para poder reverter sua árvore em uma única operação se algo der errado.
  • Você pode realizar uma série de confirmações temporárias ao refatorar uma parte complexa do código para que possa dividir ou retroceder caso acabe quebrando alguma coisa no processo.
  • Você pode realizar uma confirmação, iniciar uma nova ramificação ou criar uma marcação quando quiser tentar algo experimental, podendo retornar ao estado da árvore de trabalho atual a qualquer momento.
por 17.09.2013 / 09:45
fonte
0

Confirmar algum código-base quebrado é aceitável desde que seja local.

Por quê?

  • É essencial usar o compromisso como um ponto de salvaguarda no seu desenvolvimento
  • Mostra um padrão de pensamento usado durante o desenvolvimento do produto.
  • O não interrompe a colaboração .

No entanto, quando há uma equipe de programadores, a filosofia da casa de programação é primordial e substitui os comportamentos individuais de commit. Algumas casas de programação decidem registrar todo o progresso, enquanto outras decidem apenas confirmar o código que resolve um recurso. Nesse caso, o valor ( custo , do ponto de vista de gerenciamento de software) de um commit quebrado é terrível:

  1. o tempo usado para mais recursos agora é gasto corrigindo erros ...
  2. o corte de desenvolvimento não é atendido ...
  3. o produto não é enviado no prazo

Outros pontos podem ser acrescentados a estes três, colocando seus efeitos em cascata exponencialmente no colapso da empresa ... claro, isso tem que ser um efeito de um comprometimento crônico habitual de códigos ruins.

    
por 16.09.2013 / 17:42
fonte
0

Eu não acho que seja correto cometer código quebrado.

O que acontece se

  • Um hot fix urgente é necessário. Base de código está em um estado quebrado. Você é forçado a reverter, corrigir e implantar.

  • Alguém começa a trabalhar no mesmo ramo sem saber que você cometeu um código quebrado. Eles podem estar perseguindo um "arenque vermelho", pensando que suas mudanças quebraram alguma coisa.

  • Você decide sair da empresa, sair de férias ou não pode ir trabalhar por qualquer motivo. Seus colegas terão que cavar fundo para descobrir o que está quebrado e por que ele foi comprometido em um estado quebrado.

  • Alguém implementa seu 'código quebrado'? Isso pode ser um "fim de jogo" se você estiver trabalhando com dados pessoais ou com um provedor de pagamentos.

Responder a @WarrenT

Concordo com você que, em um mundo ideal em que todos trabalham em um ramo de recursos, cometer um código que não funciona pode funcionar. Eu trabalhei em grandes projetos e, mesmo assim, houve casos em que várias pessoas tiveram que trabalhar em um único ramo de recursos. Eu também vi pessoas cometendo 'não trabalhando' código para o ramo principal porque o lançamento estava a semanas de distância e eles planejavam consertá-lo no dia seguinte. Todas essas coisas são candidatas a um desastre e eu acredito strongmente que elas devem ser evitadas a todo custo.

    
por 16.09.2013 / 17:15
fonte
-1

Algumas perguntas ajudam você a determinar se não há problema em confirmar um código que não funciona:

  1. Você está sendo sobrecarregado?
  2. Seus companheiros de equipe quebram constantemente a compilação?
  3. Sua base de código é uma bagunça e aparentemente não pode piorar?

Se você disser sim para qualquer um dos itens acima, então sim, não há problema em cometer código que não funciona.

Lembre-se de corrigir o problema o quanto antes, cobrir com todos os testes de unidade aplicáveis e pedir desculpas por quebrar a compilação.

    
por 13.04.2015 / 21:00
fonte