Quando um controle de versão é muito grande? [fechadas]

Já ouvi em vários lugares "Não faça grandes confirmações", mas nunca entendi o que é uma confirmação "grande". É grande se você trabalhar em um monte de arquivos, mesmo que haja algum relacionado? Em quantas partes de um projeto você deve trabalhar ao mesmo tempo?

Para mim, tenho problemas para tentar fazer "pequenas confirmações", pois esqueço ou crio algo que cria outra coisa que cria outra coisa. Você acaba com coisas assim:

Fila de saída personalizada criada

Robô
-Novo campo msgQueue, que nada mais é que um SingleThreadExecutor
-sendMsg bloqueia até que a mensagem seja enviada e adiciona espera entre quando as mensagens são recebidas
enviei
Chamadas -adminExist atualizadas (consulte o controlador)
- Chamadas removidas para sendMessage

Controlador
-Novo campo msgWait indica tempo de espera entre mensagens
-Iniciar os plug-ins de serviço movidos para reloadPlugins
-adminExists mudou do servidor por causa de administradores globais. Cheques no canal,
servidor e nível global

Admin
-New métodos getServer e getChannel que obtêm o objeto apropriado Admin
pertence a

BotEvent
-toString () também mostra extra e extra1 do show

Canal
-channel renomeado para nome
- Erro de digitação corrigido no canal (int)

Servidor
-Moved adminExists to Controller

PluginExecutor
- Pequenos testes adicionados, serão removidos mais tarde

JS Plugins
-Atualizado para mudanças na estrutura
Substituído InstanceTracker.getController () com Controller.instance
-VLC conversa agora em arquivo próprio

Várias atualizações e alterações do projeto NB

---

Arquivos afetados
Modifique /trunk/Quackbot-Core/dist/Quackbot-Core.jar
Modifique /trunk/Quackbot-Core/dist/README.TXT
Modifique /trunk/Quackbot-Core/nbproject/private/private.properties
Modifique /trunk/Quackbot-Core/nbproject/private/private.xml
Modifique /trunk/Quackbot-Core/src/Quackbot/Bot.java
Modifique /trunk/Quackbot-Core/src/Quackbot/Controller.java
Modifique /trunk/Quackbot-Core/src/Quackbot/PluginExecutor.java
Modifique /trunk/Quackbot-Core/src/Quackbot/info/Admin.java
Modifique /trunk/Quackbot-Core/src/Quackbot/info/BotEvent.java
Modifique /trunk/Quackbot-Core/src/Quackbot/info/Channel.java
Modifique /trunk/Quackbot-Core/src/Quackbot/info/Server.java
Modifique /trunk/Quackbot-GUI/dist/Quackbot-GUI.jar
Modifique /trunk/Quackbot-GUI/dist/README.TXT
Modifique /trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jar
Modifique /trunk/Quackbot-GUI/nbproject/private/private.properties
Modifique /trunk/Quackbot-GUI/nbproject/private/private.xml
Modifique /trunk/Quackbot-GUI/src/Quackbot/GUI.java
Modifique /trunk/Quackbot-GUI/src/Quackbot/log/ControlAppender.java
Excluir /trunk/Quackbot-GUI/src/Quackbot/log/WriteOutput.java
Modifique /trunk/Quackbot-Impl/dist/Quackbot-Impl.jar
Modifique /trunk/Quackbot-Impl/dist/README.TXT
Modifique /trunk/Quackbot-Impl/dist/lib/Quackbot-Core.jar
Modifique /trunk/Quackbot-Impl/dist/lib/Quackbot-GUI.jar
Modifique /trunk/Quackbot-Impl/dist/lib/Quackbot-Plugins.jar
Modifique /trunk/Quackbot-Impl/lib/javarebel.stats
Adicione /trunk/Quackbot-Impl/lib/jrebel.info
Modifique /trunk/Quackbot-Impl/nbproject/private/private.properties
Modifique /trunk/Quackbot-Impl/nbproject/private/private.xml
Modifique /trunk/Quackbot-Impl/nbproject/project.properties
Modifique /trunk/Quackbot-Impl/plugins/CMDs/Admin/reload.js
Adicione / trunk / Quackbot-Impl / plugins / CMDs / Operator / hostBan
Modifique /trunk/Quackbot-Impl/plugins/CMDs/Operator/mute.js
Modifique /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/curPlaying.js
Modifique /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/lfautomode.js
Modifique /trunk/Quackbot-Impl/plugins/listeners/onJoin.js
Modifique /trunk/Quackbot-Impl/plugins/listeners/onQuit.js
Modifique /trunk/Quackbot-Impl/plugins/testCase.js
Adicione /trunk/Quackbot-Impl/plugins/utils/whatsPlaying.js
Modifique /trunk/Quackbot-Impl/src/Quackbot/impl/SandBox.java
Adicione / trunk / Quackbot-Impl / vlc_http
Adicione /trunk/Quackbot-Impl/vlc_http/current.html
Modifique /trunk/Quackbot-Plugins/dist/Quackbot-Plugins.jar
Modifique /trunk/Quackbot-Plugins/dist/README.TXT
Modifique /trunk/Quackbot-Plugins/dist/lib/Quackbot-Core.jar
Modifique /trunk/Quackbot-Plugins/nbproject/private/private.properties
Modifique /trunk/Quackbot-Plugins/nbproject/private/private.xml
Modifique /trunk/Quackbot-Plugins/src/Quackbot/plugins/JSPlugin.java
Adicione / trunk / Quackbot-Plugins / vlc_http
Adicione /trunk/global-lib/jrebel.jar

Sim....

Então, para perguntas:

• Quais são alguns fatores para quando um commit se torna muito grande ( coisas não óbvias )?
• Como você pode impedir tais confirmações? Por favor, especifique
• E quando você está nos estágios semi-iniciais do desenvolvimento, quando as coisas estão se movendo rapidamente? Confirmações enormes ainda estão bem?

Para mim, tenho problemas para tentar fazer "pequenas confirmações", pois esqueço ou crio algo que cria outra coisa que cria outra coisa.

Isso é um problema. Parece que você precisa aprender a dividir seu trabalho em pedaços menores e mais gerenciáveis.

O problema com confirmações grandes são:

• Em um projeto para várias pessoas, uma maior chance de seus commits causarem conflitos para outros desenvolvedores resolverem.
• É mais difícil descrever com precisão o que foi feito nas mensagens de log.
• É mais difícil rastrear a ordem em que as alterações foram feitas e, portanto, entender a causa dos problemas.
• Aumenta a probabilidade de perder muito trabalho não comprometido.

Às vezes, grandes confirmações são inevitáveis; por exemplo, se você precisar alterar uma API principal. Mas isso normalmente não é o caso. E se você se encontra nessa situação, provavelmente é uma boa idéia criar um ramo e fazer seu trabalho lá ... com muitos pequenos commits ... e se reintegrar quando terminar.

(Outro caso é quando você faz uma importação inicial, mas isso NÃO é problemático da perspectiva dos problemas listados acima.)

O princípio da responsabilidade única.

Toda confirmação de controle de origem deve servir apenas a um propósito. Se você precisar colocar a palavra "e" ou "também" em seu resumo, precisará dividi-la.

É muito comum acabar com muitas alterações independentes ou semid relacionadas na sua cópia de trabalho. Isso é chamado de "problema de cópia de trabalho emaranhada" e é realmente muito difícil de evitar, mesmo para desenvolvedores disciplinados. No entanto, o Git e o Mercurial oferecem ferramentas para resolvê-lo - git add -p ou chunk selection e Mercurial Queues no TortoiseHg, respectivamente.

Imagine que o cliente pediu para fazer uma alteração específica - por exemplo, para adicionar uma regra de que algo ou outro não pode ser feito dentro de dois dias da data "qualquer que seja". Depois que você fez a alteração, eles mudam de idéia. Você desejará reverter seu commit. Se tudo está misturado com algumas coisas sobre como alterar a ordem de classificação de relatórios não relacionados, sua vida é uma miséria.

Um item de trabalho, um changeset. Um pedido do cliente, um changeset. Uma coisa sobre a qual você pode mudar de idéia é uma mudança. Às vezes, isso significa que é uma única linha de código. Às vezes, são dez arquivos diferentes, incluindo o esquema do banco de dados. Isso é bom.

Confirmações grandes são quando você tem toneladas de alterações que nem sempre estão no mesmo balde. Se eu mudar a lógica do controlador, o modelo de conexão com o banco de dados e alguns outros. scripts, eu não deveria agrupar tudo em um commit.

Prevenção é fazer confirmações de acordo com o que você está concluindo. No exemplo acima, eu confirmaria após a lógica do controlador, após o trabalho do banco de dados e após os scripts. Não adie cometer simplesmente porque você sabe o que mudou. Outras pessoas analisarão sua mensagem de log de confirmação de "Coisas alteradas" e se perguntarão o que você estava fumando.

As importações iniciais são provavelmente as maiores confirmações que você já deve ter. Configurando um sistema a partir do zero? Claro que tem alguns grandes commits. Depois de nivelá-lo, é hora de manter as coisas organizadas.

Se você sabe que vai trabalhar com um grande pedaço de código de antemão, sugiro que você crie um ramo para seu recurso específico, enquanto extrai periodicamente o código da linha principal para garantir que seu código permaneça sincronizado. Quando você terminar de trabalhar na ramificação, mesclar todas as suas alterações novamente na linha principal. Dessa forma, outros membros da equipe não ficarão surpresos e / ou aborrecidos quando virem um grande comprometimento. Além disso, há muito menos chance de quebrar as coisas. Continue praticando para dividir as coisas em commits menores. Com o tempo, isso se tornará uma segunda natureza.

Este exemplo mostra um commit muito grande.

Como regra geral, descreva a alteração em uma frase ou em uma linha de texto. (Com base nessa regra, o commit deve ser dividido em 10 a 15 menores.) Se você não puder comentar adequadamente um commit em uma linha, ele já será muito grande.

Para praticar confirmações menores, faça anotações no seu bloco de notas (ou no Bloco de Notas) do que você já mudou ou adicionou. Confirme antes que se torne uma lista longa ou antes de fazer uma alteração no código não relacionada ao que você já possui no bloco de notas.

No meu campo (modelagem física), descubro hoje um erro na saída que não estava no repositório há 6 meses. Quando isso acontecer, farei uma pesquisa binária nas revisões:

1. Executar modelo de 3 meses atrás
2. Se o erro ainda estiver em produção, execute o modelo de 4,5 meses atrás
3. ... repita até encontrar o commit que gera uma saída ruim

Quando o bug foi introduzido em um cometimento monstruoso, tenho que me sentar com um pente fino para encontrar a fonte do problema. Se o commit tocou em um pequeno número de arquivos, é menos doloroso rastrear as linhas de código que introduziram o problema.

Eu recomendaria dividir seu problema em uma série de tarefas menores (idealmente, coloque cada tarefa em um rastreador de erros). Faça uma confirmação ao concluir cada tarefa (e feche esse bug / recurso no seu rastreador de erros).

Não é o tamanho do commit que realmente importa, é o escopo da mudança que deve determinar como seus compromissos são organizados.

Você pode, por exemplo, alterar todas as instâncias de __macro1para __macro2em uma grande base de códigos, que altera 200 arquivos. 200 compromissos não seriam sãos nesse caso.

O que você quer terminar é poder extrair o repositório com uma única revisão e fazer com que a construção funcione. Você mudou delibfoo para libbar? Espero que essa mudança inclua a atualização de seus scripts de compilação e Makefiles (ou o que for aplicável).

Às vezes, pode ser necessário fazer uma série de alterações experimentais que realizam uma coisa; nesse caso, você precisa determinar qual escopo é mais importante para você, se precisar reverter mais tarde. Um depende do outro? Confirme todos de uma vez em uma única revisão. Caso contrário, nesse caso, sugiro um commit por alteração. Você deve fazer algo assim em outro ramo ou em outro repositório de qualquer maneira.

Embora sim, você tem o poder de reverter um único arquivo para uma revisão anterior (o que faz com que um arquivo seja retirado de um compromisso maior). Isso faz com que você realmente estrague ferramentas como a bissecção mais tarde no caminho e polua a história.

Se você parar e pensar "Ok, os testes são aprovados, acho que isso funciona .. mas se der errado, posso voltar com facilidade?" .. você vai acabar fazendo compromissos sensatos.

O que devemos entender aqui é que "Grande", neste contexto, é sobre o número de alterações distintas, não o tamanho físico do commit (embora geralmente os dois andem de mãos dadas).

Não é uma questão de "não faça grandes commits", como fazem fazer pequenas commits - o ideal sendo a cometer pequena auto-contido mudanças.

Está claro pelo changelog que você tem uma série de coisas que poderiam ter sido cometidas separadamente (e com segurança) e, portanto, é bastante evidente que é muito grande.

A razão pela qual isso pode ser um problema é que o seu último commit é o seu ponto de referência para as alterações que você está fazendo no momento. Se, por exemplo, você acertar o primeiro bit e errar o próximo, não será fácil. para reverter o seu trabalho até o ponto em que você começou a cometer erros (BTDTGTTS).

É claro que às vezes as mudanças são grandes - refatoração em larga escala - e como sugerido por outras pessoas, é aqui que você precisa se ramificar, dessa maneira, embora o seu comprometimento individual possa interromper as coisas que são separadas do tronco principal de desenvolvimento. problema e você começa a se comprometer cedo e com frequência.

Mais uma coisa - se algo aparecer no meio do seu trabalho que requer atenção mais imediata, você precisará alterá-lo separadamente (idealmente em um conjunto de pastas completamente distinto) e enviá-lo separadamente.

O verdadeiro desafio de tudo isso não é a mecânica, é a mentalidade - que um commit não é apenas uma cópia de backup que você faz de vez em quando, mas que cada commit é um pedregulho ao longo do caminho e que não há nada errado com muitos de pequenos commits e que juntar coisas diferentes em um commit da multidão é tão ruim quanto juntar bits de funcionalidade vagamente relacionados em um pedaço de código.

No mínimo, treine-se para se comprometer sempre que pensar "gosto do meu progresso até agora e não quero perdê-lo se as mudanças que estou prestes a fazer forem um desastre". Então você tem a opção de aproveitar o VCS para eliminar quaisquer becos sem saída que você tentou ou código de depuração especial que você adicionou para rastrear um problema. (por exemplo, com git reset --hardou rm -rf *; svn update)

Não existe uma regra rígida e rápida, nenhuma linha divisória além da qual o seu commit é muito grande.

Não é no entanto uma orientação que as submissões menores são melhores, a razão (ou seja, comprometendo cada linha é probaby excessiva).

Eu mantenho esses tipos de diretrizes em mente:

• Uma única confirmação deve incluir alterações para apenas uma correção de bug
• Um único commit não deve incluir mais de meio dia de trabalho
• Um único commit não deve interromper a construção

Claro - é isso que eu tenho em mente - YMMV. Diferentes desenvolvedores favorecem diferentes níveis de granularidade.

Quanto menor o commit, mais fácil será encontrar exatamente de onde vem uma regressão em potencial.

Idealmente, um commit deve ser atômico , no sentido da menor alteração coerente na base de código (relacionada a um bug, recurso, etc.).

Quanto às dicas específicas para manter pequeno o tamanho da confirmação, isso depende muito do seu VCS e de como está configurado: você deve poder confirmar localmente ou trabalhar em sua própria filial no servidor.

A chave é se comprometer com sua ramificação "privada" toda vez que você fizer uma alteração atômica e, em seguida, você poderá mesclar regularmente sua ramificação, por exemplo, toda semana.

Usando um dvcs, seu fluxo de trabalho pode ser assim:

code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
...
git push         // push your previous commits to the team server

Usando um vcs centralizado:

svn copy trunk my_feature_branch  // create your private branch
svn co my_private_branch          //
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
...
svn merge my_feature_branch trunk  // all your previous commit are merged to main/master branch

Você provavelmente já ouviu o ditado de que perfeição é quando você não pode tirar nada mais. Isso também deve descrever seu padrão para o tamanho da confirmação.

Depende do seu projeto onde está o tamanho "perfeito". Se você estiver enviando para clientes externos, um bom tamanho pode ser o menor incremento que seria confortável se não terminasse o próximo a tempo. Se você estiver criando aplicativos internos implantados com frequência, o melhor tamanho pode ser o menor incremento que não quebra nada (e aproxima você de onde você deseja estar).

Os sistemas modernos de controle de versão ajudam a criar boas confirmações com ramificação fácil, rebaseamento interativo, área de preparação, etc.

As mensagens de confirmação devem ter apenas uma linha (e para o git max 60 caracteres). A quantidade de código que está sendo confirmada deve ser pequena o suficiente para manter a mensagem descritiva dentro desse limite.

Eu costumo me comprometer toda vez (ainda mais agora que mudamos para o git). Eu tenho um pedaço pronto, pois permite capturar o "por que" as coisas foram feitas dessa maneira.

Às vezes, você trabalha o dia todo em vários nomes logicamente distintos e se esquece de confirmar seu código no meio. O uso git citoolpode ser muito útil para dividir seu trabalho em bons pedaços pequenos no final do dia, mesmo que você não tenha sido tão cuidadoso durante o dia enquanto estava trabalhando.

git citool pode permitir que você selecione quais blocos específicos de um arquivo (ou linhas específicas) a serem confirmadas em uma confirmação específica, para que você possa dividir as alterações (sem sobreposição) feitas no mesmo arquivo em várias confirmações.

(Parece que você usa o Subversion. Não conheço uma ferramenta que faça isso no Subversion, mas você pode usar git-svno adaptador Subversion para git, que mudará sua vida.)

Quanto maior o commit, maior a probabilidade de você quebrar a compilação e ser pago pelo resto da sua equipe. Eu tento confirmar alterações duas vezes por dia. Pouco antes do almoço e antes de eu ir para casa. Então, às 12h e às 16h30, tento fazer tudo funcionar e pronto para confirmar. Acho que essa prática funciona para mim.

Para responder suas perguntas:

1) Para mim, o commit padrão é considerado grande se estiver fazendo mais de uma coisa. Por isso, quero dizer corrigir um bug ou adicionar um recurso.

2) Impedir tais confirmações, tornando um hábito e uma regra se comprometer sempre que você terminar algo.

3) Nos estágios semi-iniciais do desenvolvimento, permito que os commits incluam a primeira criação dos arquivos que serão usados ​​posteriormente.

Gostaria de observar que, ao terminar, quero dizer que todos os bugs que você pode identificar foram corrigidos e você não quebrará a compilação ao cometer.

Sim, isso gera um grande número de confirmações, mas permite reverter exatamente o que quebrou as coisas, em vez de ter que reverter uma grande série de alterações que foram confirmadas ao mesmo tempo em que apenas uma das alterações está causando um problema.

Eu também gostaria de salientar que as regras mudam um pouco para os sistemas de controle de versão distribuído (DVCS) como Mercurial e Git. No caso de você estar usando um desses, você confirma sempre que faz uma alteração, mas ainda não a testou e depois envia para o repositório central quando está funcionando. É preferível, pois permite revisar mais alterações no seu código sem se preocupar em interromper a compilação.

No meu caso, estou tentando confirmar arquivos de um servidor no sistema de repositório (SVN). Esse é o commit inicial e não deseja baixá-lo, pois é um projeto muito grande (alguns GB) e eu quero fazer o commit inicial no servidor do cliente.

O problema é que o cliente está em um servidor compartilhado, o cliente svn é morto (ou qualquer outro software) se for executado mais de um minuto.

Uma alternativa seria baixar o projeto no meu computador e fazer a confirmação inicial a partir daí, mas estou interessado em saber se existe uma opção no SVN para dividir a confirmação grande em mais, algo semelhante aos métodos de transações.

O desenvolvedor antes de mim nunca usou um sistema de controle de versão.

A empresa em que trabalho força uma revisão de código por pares para cada confirmação. Portanto, qualquer confirmação que torne difícil para um colega descobrir o que está acontecendo e revisar em um período de tempo razoável é muito grande.