Melhores hábitos de controle de versão para desenvolvedores solo?

35

Sou um único desenvolvedor no meu trabalho e compreendo os benefícios do VCS; Eu acho difícil manter boas práticas. No momento, estou usando o git para desenvolver principalmente aplicativos da web (que nunca serão abertos devido ao meu trabalho).

Meu fluxo de trabalho atual é fazer muitas alterações no site de desenvolvimento, testar, revisar, testar, ser feliz e confirmar as alterações e, em seguida, enviar o commit para o site ativo (se estiver trabalhando em uma nova grande alteração; Eu só posso comprometer uma vez por semana, mas meu IDE tem um bom histórico de desfazer para coisas não confirmadas).

Basicamente, estou usando apenas o git ao alternar entre máquinas (por exemplo, computador de trabalho dev para computador de desenvolvimento doméstico ou para máquina viva), mas durante o dia eu realmente não vejo o benefício. Isso me leva a ter longas listas de mudanças de lavanderia (e tenho dificuldade em encontrar uma boa mensagem para cada commit; e sempre que estou com pressa - tenho a tendência de deixar mensagens ruins como 'várias mudanças em admin e templates').

Com que frequência devo me comprometer? Cada troca de uma linha deve receber um commit? Devo me comprometer antes de qualquer teste (por exemplo, pelo menos para erros de sintaxe / compilação e, em seguida, tenho que desfazê-lo totalmente; como a ideia não funcionou ou a mensagem é uma mentira)?

Devo me certificar que eu me comprometa todas as manhãs / tarde antes de eu parar de trabalhar para o jantar enquanto ainda está fresco? O que estou perdendo por ter maus hábitos de VCS?

    
por dr jimbob 10.01.2012 / 18:55
fonte

10 respostas

24

Você está sentindo muita falta.

Eu também sou solo, de certa forma. Eu me comprometo toda vez que faço uma mudança significativa, ou antes de começar uma significativa, para que eu possa voltar, se eu estragar as coisas, e de vez em quando, mesmo que eu não esteja fazendo nada grande. Nem todos os dias realmente, mas perto. Às vezes algumas vezes por dia.

O que eu ganho é que posso voltar a qualquer hora que quiser. Que é muito. Além disso, ter os ramos ordenados ajuda.

Eu acho que isso me dá muita ordem.

Estou usando o svn e estou ficando cansado disso. Mas não pode gastar mais tempo aprendendo nada mais.

Boa sorte.

    
por 10.01.2012 / 19:06
fonte
17

Você deve se comprometer com frequência. Você certamente deve se comprometer depois de alcançar algum marco lógico. Se isso levar mais de um dia, você deve pelo menos comprometer-se no final do seu dia de trabalho, ou, melhor ainda, dividir seu trabalho em partes menores.

Existem muitas razões para isso. Por exemplo, e se o seu computador travar? É muito melhor perder apenas um dia de trabalho do que uma semana ou um mês. Outra razão é que os commits frequentes facilitam o isolamento de um bug. Você pode fazer uma pesquisa binária e descobrir qual pequena alteração causou o bug.

Outra coisa: antes de você cometer, você deve fazer um diff e olhar todas as mudanças que você fez. Isso permite verificar se todas as alterações fazem sentido e se você não esqueceu de nada. Isso também ajuda você a criar uma mensagem de confirmação melhor. E, claro, esse é outro motivo para se comprometer com frequência: é muito mais fácil passar por um dia de mudanças do que um mês.

    
por 10.01.2012 / 19:07
fonte
9

Para aproveitar ao máximo o CVS, você deve trabalhar em um recurso / correção de bugs por vez e confirmar quando esse recurso / correção de bugs for concluído. Ao fazer isso, você ganha:

  • as mensagens de confirmação serão mais fáceis de criar e farão mais sentido;
  • acompanhamento mais fácil de futuros bugs de volta para as alterações que os introduziram;
  • mais fácil reverter para um estado anterior (mesmo que isso signifique perder um recurso com falha, mas mantendo as correções de erros que ocorreram depois).

Além disso, como você alterna entre computadores, você deve ter pelo menos duas ramificações:

  • uma ramificação "Pronto para ir" que sempre funciona (exceto os bugs em que você está trabalhando no ramo de desenvolvimento, é claro)
  • uma ramificação de desenvolvimento que pode estar em um estado inatingível de tempos em tempos (como durante sua viagem de volta para casa do trabalho;).
por 10.01.2012 / 21:04
fonte
6

Should each one-line change get a commit?

Se é isso que corrige um bug, com certeza.

What I am missing out on by having bad VCS habits?

Eu trabalhei com um cara que tinha "maus hábitos de VCS". Ele adorava trabalhar sozinho e era responsável por uma linha de produtos que gerava algo como $ 1.000.000 / ano. Ele só se comprometeria quando o chefe o incomodava. Então um dia seu disco rígido caiu. Depois de obter um substituto criado para ele, descobrimos que seu último check-in foi de 6 meses antes. Como o VCS era Source Safe, você pode adivinhar o que mais deu errado - o último commit foi corrompido. Tivemos que voltar mais de um ano para obter uma versão não corrompida de sua linha de produtos. Ele não foi demitido, mesmo que ele deveria ter sido.

Outra anedota envolve a mim mesmo. Eu costumava armazenar código para hobby e projetos de pesquisa em discos rígidos removíveis. Um dia, meu apartamento foi arrombado. O laptop (que estava quebrado) e todos os discos rígidos removíveis foram roubados. Todo DVD (com exceção do Red Dawn) foi roubado. Nenhum dos computadores desktop foi roubado. Se eu tivesse o controle de fontes externas, eu não perderia 15 anos de projetos, especialmente porque alguns eram baseados em projetos acadêmicos - muitos dos professores deixaram o setor acadêmico para ir para a indústria privada, então esses projetos desapareceram em um buraco negro corporativo. código perdido impossível de recuperar.

How often should I be committing?

Eu divido em algumas métricas:

  • Quanto trabalho você está disposto a perder se o seu computador morrer? ou é roubado?

  • Se isso corrigir o Bug_1234, verifique o código com o comentário "correções Bug_1234".

  • Se esta é uma entrega / marco lógico, marque-a com um comentário como "Bug_1234, form_xyz" (ou Task_1234, conforme apropriado).

  • Sempre verifique o código na sexta-feira à noite antes de ir para casa. Também fazer um check-in (ou desfazer os check-out) de tudo antes de sair de férias.

  • Sempre que a política da empresa determinar.

por 10.01.2012 / 22:23
fonte
5

Não pense em termos de alterações no número de linhas. Pense em pedaços de funcionalidade. O VCS permite que você forneça um cabeçalho em um local central para cada fragmento de funcionalidade, para que você possa ver facilmente "o que aconteceu aqui" com, por exemplo, git log.

Além disso, os Eclipse do IDE permitem que você aponte para uma determinada linha e vá para o commit que a colocou na forma que você vê. Em outras palavras, você pode ir diretamente de uma linha de origem para o commit. Se o commit é pequeno e tem uma boa mensagem, é muito mais útil do que "toneladas fixas de bugs".

    
por 10.01.2012 / 22:57
fonte
4

Eu diria que a maior coisa que você está perdendo ao agrupar as mudanças juntas é a capacidade de rastrear quando e onde os bugs foram introduzidos.

Na minha experiência, houve algumas vezes em que algum bug foi notado duas a três semanas após ter sido introduzido e ter que peneirar uma semana de commits é difícil, muito tempo depois do fato. Nesses casos, era útil simplesmente pesquisar binário por meio dos commits para rastrear qual alteração individual causou o problema. Esses bugs eram principalmente erros de uso de memória no código C ++, então isso pode não acontecer com tanta frequência para o seu projeto.

Outros benefícios entram em jogo quando se desenvolve em equipe - comentários simples de commit, mesclagens mais fáceis, relacionando commits a correções de bugs, etc.

Eu diria que com o seu fluxo de trabalho, se você começar a se comprometer diariamente ou semicor diárias, precisará usar marcações ou marcadores para acompanhar qual versão do código está em uso no site ao vivo. Eu diria que é a coisa mais importante para acompanhar.

    
por 10.01.2012 / 19:14
fonte
4

Eu também sou desenvolvedor solo, uso o SVN e adoro isso. Eu até escrevi uma ferramenta para converter a estrutura do meu banco de dados e os dados de teste nele para xml, para que eu possa incluir isso no controle de origem.

Eu costumo cometer sempre que eu completei uma unidade autônoma de trabalho. Às vezes, se eu executar um monte de correções de linha única triviais e não relacionadas aqui e ali, eu comprometo todas elas juntas, mas se ocorrer uma correção de linha única entre duas grandes unidades autônomas de trabalho não relacionadas, commit, não há nada de errado com isso.

Além disso, sempre escrevo código que compila e quase sempre código que também passa em todos os testes básicos. Se não, eu me certifico de incluir "DO NOT WORK" na mensagem de commit. O único caso quando isso acontece é quando eu fiz mudanças importantes que eu não quero perder, mesmo que elas não funcionem ainda, e sobre isso eu estou prestes a embarcar em uma grande aventura de refatoração que eu não tenho certeza se será bem sucedido. Então, eu uso o repositório como um backup do trabalho que fiz até agora antes de arriscar a bagunçar tudo e ter que jogá-lo fora.

Isso significa que sempre me comprometo quando meu código-fonte precisa ser confirmado; Não faz absolutamente nenhum sentido ter o commit da manhã ou regras de commit noturnas. É o estado em que o código está em que determina se é ou não hora de cometer.

As mensagens que você coloca no repositório não importam muito. Se você absolutamente não consegue criar algo significativo, é melhor enviá-lo com uma mensagem em branco do que não se comprometer quando deveria.

Se você não consegue pensar em uma boa mensagem de commit porque tudo que você faz soa estúpido, tenha em mente que está tudo bem; Espera-se que as mensagens de commit digam o óbvio, de modo que elas parecem estúpidas quando você as escreve. Mas confie em mim, se você precisar examinar as revisões antigas um mês depois, ficará agradecido até mesmo pelas mensagens estúpidas sem mensagens.

    
por 10.01.2012 / 21:33
fonte
1

Confirme cada vez que fizer uma mudança "lógica". Por exemplo, se você está implementando um novo recurso, você está fazendo isso passo a passo. Cada um desses passos geralmente depende um do outro. Assim, você pode apenas confirmar essas etapas separadamente e explicar na mensagem de commit por que cada etapa é necessária.

A mensagem de commit é realmente importante. Você deve evitar dizer ao que você está fazendo, diga por que você está fazendo isso. O código já documenta as alterações, mas em 6 meses você ficará feliz em ver por que você as fez.

Isso também é útil se, por acaso, alguém pular e você não estiver mais sozinho. Mesmo apenas para você, um histórico limpo facilita o uso de um git blame para saber quando e por que a linha que tem um bug foi alterada.

Fazer pequenos commits em vez de mudanças em big ball of mud também permite que você teste o estado intermediário. Você pode esconder as alterações se precisar liberar algo com urgência. Se você introduzir um bug enquanto ele funcionava antes, você pode esconder e verificar se são as alterações não confirmadas que introduzem o bug, ou se isso ocorreu em uma confirmação mais antiga.

Você também pode liberar o poder de git bissect que lhe dirá o commit desse bug desagradável. Se o commit é de 2.000 linhas, ainda ajuda, mas não tanto ...

Outra coisa é que é o primeiro passo para integração contínua (CI) e, em seguida, implantação contínua (CD). O CI e seus testes podem ser acionados em um novo commit, portanto, informando cada vez que você envia as mudanças se elas quebram alguma coisa ou não. Desta forma, você pode saber se é seguro implantar ou não, e ser notificado disso no momento em que o problema é introduzido e não apenas antes de seu lançamento, quando você está com pressa.

Sobre suas outras perguntas:

  • não cometa coisas que você nem compilou, a menos que esteja disposto a reescrever seu histórico para isso (usando git rebase --interactive ).
  • uma alteração de uma linha merece um commit se tiver uma finalidade separada (corrige um bug ou não está relacionada às suas alterações não confirmadas no momento). Use git add --patch para encenar isso.
  • não há necessidade de se forçar a se comprometer antes do jantar, a menos que você tenha coisas importantes que você não pode perder. Nesse caso, você pode querer comprometer em um ramo separado o seu trabalho em andamento.
  • confirmar e enviar para um repositório remoto é um backup. Se você se comprometer e enviar apenas uma vez por semana, no pior dos casos poderá perder uma semana de trabalho.
por 16.01.2018 / 15:26
fonte
0

How often should I be committing?

Como desenvolvedor solo, eu geralmente me comprometo sempre que sinto que fiz uma mudança significativa, depois de testes básicos, e quando deixo um projeto no final da noite.

Should each one-line change get a commit?

Não, a menos que essa alteração de uma linha altere significativamente um recurso ou bug.

Should I commit before any test (e.g., at least for syntax/compiling errors and then have to totally undo it; as the idea didn't work or the message is a lie)?

Provavelmente não. Pelo menos para mim eu faço a maioria dos meus testes e codificação em uma 'cópia de trabalho' e me comprometo depois que estou feliz com minhas alterações. Em muitos IDEs, ele vai me mostrar o que mudou antes de eu realmente fazer o commit e me dar uma oportunidade de anexar notas ao commit

Should I make sure I commit each morning/afternoon before I stop working for dinner while its still fresh? What I am missing out on by having bad VCS habits?

Eu não estou muito familiarizado com VCS ou quais os maus hábitos que isso causa. Acho que compartilhei minha opinião sobre isso em resposta à primeira pergunta.

Em resposta à pergunta geral postulada, você parece estar usando principalmente commits como branches, o que é abordado em outra postagem de respondentes. Eu não tenho certeza de qual IDE você está usando que tem um bom histórico de desfazer etc, mas eu não encontrei um que eu ache que era bom além de reinicializações do IDE e se movendo entre as máquinas.

    
por 10.01.2012 / 23:46
fonte
0

Sou um committer habitual e descobri que isso combina comigo, mas admito que minhas mensagens de commits são quase sempre semelhantes,

Age:  9 mins [*] Working on implementing and testing PaintSystem.
Age: 17 mins [*] Working on implementing and testing PaintSystem.
Age: 37 mins [*] Working on implementing and testing PaintSystem.
Age: 52 mins [*] Working on implementing and testing PaintSystem.

Então, não posso dizer exatamente que fazer commits freqüentes e habituais para minha ramificação (mercurial) incentivou exatamente os logs de confirmação mais detalhados. Às vezes, eu até mesmo faço o código a meio caminho, se, digamos, minha esposa me pedir para sair para jantar, e nesse momento eu irei apenas copiar apressadamente e usar a mensagem anterior "Trabalhando em [...]".

Meus padrões de registro de commits são tipicamente como "Working on [...] Working on [...] Working [...] Completed [...] Started working on [...] Working on [...] Completed [...] Started working on [...]"

Por outro lado, ele salvou minha bunda. Às vezes eu me deparo com um caso extremo que eu não esperava e testei, e nesse ponto os commits frequentes me ajudam a descobrir exatamente onde eu apresentei o erro.

Então, eu não sei sobre os melhores hábitos e certamente não sou um a ouvir, na medida do ideal, os hábitos de logging, mas certamente posso dizer que se comprometer com mais frequência pode definitivamente ajudar quando você precisa executar um regressão.

Should each one-line change get a commit?

Eu cometi alterações de uma linha antes, mas geralmente as mais complicadas e talvez eu estivesse com pouco tempo. Meus commits nem sempre se assemelham a unidades de trabalho perfeitas e completas ou a mudanças. Como dito, às vezes eles são apenas o resultado da minha esposa me pedindo para sair para jantar inesperadamente.

TBH muitos dos meus commits que seguem que "Working on [...]" log padrão não estão modelando unidades de mudança coerentes (porque eu geralmente não consigo criar uma mensagem melhor que "Working on [...]" ) mas apenas o resultado de eu dar uma pausa, como fazer uma xícara de café. A mensagem "Completed [...]" indica o final dessa unidade de trabalho e, com frequência, escrevo uma mensagem muito mais detalhada junto com as primeiras mensagens do tipo "Started working on [...]" quando começo a trabalhar em algo. Se você fizer uma média de commits como uma vez a cada 15 minutos, então as mensagens "Trabalhando [...]" serão mais como intermediárias do que alguém pode confirmar em um commit mais volumoso com uma mensagem mais detalhada.

Should I commit before any test (e.g., at least for syntax/compiling errors and then have to totally undo it; as the idea didn't work or the message is a lie)?

Eu apenas vou em frente e confirmo isso antes mesmo de executar testes às vezes (novamente, se eu tiver um evento inesperado). Além disso, mesmo que eu esteja sozinho, eu faço push para um servidor (apenas um rodando aqui em casa em uma LAN) que faz o CI. Isso pode parecer um exagero, mas não sei, eu me acostumei tanto a me apoiar nisso em meus antigos locais de trabalho. Além disso, não quero ser incomodado em ter que executar todos os testes de unidade e integração manualmente a cada vez. Eu gosto de ter tudo amarrado a empurrar. Se um teste falhar, é fácil trabalhar de forma progressiva, onde faço a regressão, corrijo o erro na última rotação e continuo. Dito isso, eu pelo menos construo o código em uma compilação de depuração antes de confirmar.

Should I make sure I commit each morning/afternoon before I stop working for dinner while its still fresh?

Eu gosto de me comprometer antes de sair e ter uma pausa entre a programação. Eu realmente não pensei muito no porque exatamente até encontrar essa questão. Eu suponho que é para evitar que eu continue de onde eu parei sem um log de commit lá no lugar de onde eu parei que eu posso diff e assim por diante. Hum, eu preciso voltar a você sobre isso, uma vez que talvez não seja teoricamente necessário, dada a frequência com que eu me comprometo. Eu ainda me sinto mais confortável cometer e empurrar antes de deixar o computador por qualquer motivo. Parte disso pode ser o antigo medo psicológico de, digamos, o computador pegar fogo depois de eu sair e ter gerentes de projeto de volta nos dias em que estávamos usando o SVN com os desenvolvedores às vezes passando semanas sem cometer a respiração no pescoço e constantemente lembrando nos para verificar o código sempre que possível, lembrando-nos que o nosso código é propriedade da empresa. Também é um pouco mais eficiente, especialmente com o push, para que meu processo de CI possa começar a executar todos os testes enquanto estiver ausente, para que eu possa voltar e ver os resultados.

Ah, e às vezes fico um pouco bêbado depois de sair e geralmente é uma má ideia tentar escrever código complexo enquanto estou bêbado (embora nem sempre; uma vez eu criei um sistema de menu de contexto muito legal depois de ter um momento eureka enquanto bêbado, mas eu só tinha 6 cervejas e não era tão complexo de codificar). Se eu tentar fazer isso, pelo menos eu cometi o código sobriamente escrito antes de sair para voltar em direção ao invés de misturar o código bêbado com o código sóbrio, ponto em que meu log de commit pode ser lido como, "Reverting back to code written before Jagermeister shots." don ' Não faço isso com muita frequência, a menos que eu tenha uma inspiração para o código do bêbado, mas nesses casos raros, realmente ajudou muito que eu cometesse algo antes de sair e ficar bêbado.

    
por 19.12.2017 / 10:35
fonte