Um desenvolvedor deve sempre usar o controle de versão [duplicado]

41

Eu ouvi declarações sobre: "Bem, sou apenas eu trabalhando neste projeto, então não preciso colocá-lo sob controle de código-fonte" e "Não há necessidade de trabalhar com uma versão controlada projeto, é tão pequeno ".

É minha opinião que não importa quão pequeno seja o projeto, desde que esteja agregando valor ao cliente (e eles também estão pagando por isso) que nós, o desenvolvedor, devemos controlá-lo; especialmente desde a política da empresa.

Eu sou louco ou meu ponto de vista faz sentido?

Pergunta: O trabalho de desenvolvimento deve sempre ser controlado pela versão?

    
por user77232 17.12.2010 / 03:05
fonte

11 respostas

88

Ah, nossa, sim.

Eu uso SVN e Git e não posso dizer quantas vezes eles salvaram minha bunda. Mais Git do que SVN, mas não vamos começar com flamewars aqui. Isso é em projetos nos quais trabalho sozinho, assim como em projetos com os quais trabalho com outras pessoas. Não é desculpa para não, realmente.

Como humano, eu sou basicamente autorizado a fazer coisas estúpidas o tempo todo. Usando o controle de versão, eu posso continuar fazendo coisas incríveis e me comprometendo em intervalos onde isso faz sentido. Quando faço algo incrivelmente estúpido, posso simplesmente reverter minhas alterações para o último ponto em que me comprometi. Mesmo com o Git, posso reverter pedaços específicos de alterações para um arquivo em vez de todo o arquivo.

Meu controle de versão (ab?) usando fluxo de trabalho, como desenvolvedor Rails (e sim, eu sei que você usa C #, o mesmo fluxo se aplica. Apenas sub meus comandos git para seus comandos tfs ), é como isso para um novo projeto:

  • Pegue um novo recurso do Pivotal Tracker e descubra o que diabos ele deve fazer. Também conhecida como tradução de cliente para inglês.
    • Crie um novo diretório para o projeto e, em seguida, imediatamente :
    • git init
    • git add .
    • git commit -m "Initial setup for [project]"
    • git remote add origin [email protected]:radar/project.git
    • git push origin master

Agora tenho um repositório Git pronto para me comprometer, com uma ramificação master . Essa ramificação master deve permanecer sempre "pura". Os testes devem ser sempre de 100%, sem desculpas, ou alguém que vai ser demitido-muito-mal-ferido, não mencionei desculpas neste ramo. Se o recurso for suficientemente complexo o suficiente (demorando mais de uma hora ou duas ou se a alteração for mais do que uma única confirmação sensata), criarei minha própria ramificação usando git checkout -b [feature-name] , senão trabalharei com o mestre .

Neste ramo, eu posso fazer o que eu quiser. master ainda vai ser "puro" e eu posso efetivamente acabar com o lugar e então git checkout . para recuperar tudo. É nesse ramo que desenvolvo o novo recurso, fazendo commits incrementais e sensatos ao longo do caminho. Fiz uma página onde um usuário pode preencher um formulário e, em seguida, algo para lidar com esse formulário? Isso é um commit. Adicionado uma nova função para uma classe e testada? Novo commit. Eu posso estar inclinado a empurrar este branch para algum lugar para que outras pessoas possam trabalhar comigo nele, nesse caso eu iria git push origin [feature-name] e então eles poderiam clonar o repositório e git checkout origin/[feature-name] -b [feature-name] para obter minhas mudanças e nós poderíamos trabalhar juntos nele .

Quando termino o recurso, executo os testes na ramificação [nome do recurso]. Então, eu posso voltar para a ramificação master , ter certeza de que tudo ainda está "puro" executando os testes e, em seguida, git merge [feature-name] para mesclar a ramificação em mestre. Então eu corro os testes novamente para ter certeza que ainda é "puro" (lembre-se, sem desculpas) e finalmente eu envio minhas alterações para a ramificação master no GitHub.

Enxaguar, repita.

Sem controle de versão, eu estaria totalmente perdido. Eu faria coisas estúpidas e depois passaria bastante tempo manualmente rolando de volta e não tendo certeza se eu tinha tudo ou não. O controle de versão é uma ótima ferramenta para evitar a estupidez (como está testando, mas isso é um tópico tangencial) e eu realmente, strongmente encorajo isso.

Sem desculpas.

    
por 17.12.2010 / 03:24
fonte
10

Sim, um desenvolvedor deve sempre usar o controle de versão de algum tipo. Quem sabe o quão grande um projeto pode se tornar, quantas pessoas podem usá-lo ou qual bug você acabou de introduzir. O VC deve andar de mãos dadas com o armazenamento externo do projeto também.

    
por 17.12.2010 / 03:10
fonte
6

É uma decisão absolutamente pessoal.

Quanto a mim - eu coloquei na versão de controle qualquer coisa . Literalmente - qualquer coisa. Não importa - é uma lista de compras, ou fontes de projeto.

    
por 17.12.2010 / 03:08
fonte
4

Absolutamente. Se nada mais (e que um GRANDE se), liberta-o para brincar com o seu código sem se preocupar em perder a sua implementação de trabalho.

    
por 17.12.2010 / 03:08
fonte
3

Quanto trabalho de desenvolvimento você pode perder? O que acontece quando você precisa fazer uma alteração? Mais cedo ou mais tarde, você precisará disso.

    
por 17.12.2010 / 03:09
fonte
2

Não há absolutamente nenhuma razão para não fazer isso toda vez que você escreve código. Se você instalou o git, você pode até mesmo fazer isso localmente para coisas que você considera descartáveis. Basicamente, se você for editar o arquivo mais de uma vez, ele deve entrar no controle de versão. Simples assim.

Por que você não faria isso? Parece que a carga cognitiva de tentar descobrir se fazer ou não é mais do que o custo de apenas fazer isso. Sério, que esforço alguém estaria tentando salvar aqui?

A mente se sobressalta.

    
por 17.12.2010 / 03:58
fonte
1

Sim, você deve usar todo o controle de fonte de tempo ...

Mesmo que o projeto seja pequeno, há um grande benefício em usá-lo. Além disso, a sobrecarga é praticamente nenhuma se a equipe souber como usar o sistema de controle de versão.

Ter alguma rastreabilidade sobre um projeto pequeno também é importante, você pode trabalhar nos mesmos arquivos sem pisar nos dedos uns dos outros, agir como backup, etc ... etc ... então, por que não usá-lo.

    
por 17.12.2010 / 03:09
fonte
1

Sim, você está certo. O controle de versão permite reverter para um ponto anterior se você ficar preso e também permite manter backups para seu código (particularmente importante para ambientes corporativos). Se você acha que, por alguma razão, criar um repositório para este pequeno projeto é muito sobrecarga, então considere usar um VCS distribuído como o git ou o mercurial para criar um repositório localmente.

    
por 17.12.2010 / 03:09
fonte
1

Você deveria, e você também deve usar uma ferramenta de controle de código-fonte onde é muito barato fazer isso.

Eu tive o mau hábito de não usar o controle de origem imediatamente quando usei o subversion, mas com ferramentas como o Git & Mercurial, é tão barato para começar

    
por 17.12.2010 / 03:13
fonte
1

IMHO eu diria que é uma boa prática. Eu posso ser um salva-vidas naqueles casos em que você está testando soluções diferentes e quer fazer backup de uma versão sã do seu código.

Eu o uso mesmo para pequenos projetos pessoais. Eu me vi rabiscando no meu código tantas vezes xingando o Ctrl-Z sem se afastar o suficiente no tempo.

    
por 17.12.2010 / 09:53
fonte
1

Qualquer um que diga que é um idiota.

Qualquer empresa que emprega um desenvolvedor (ou gerente) que diga que não está em algum lugar que você queira trabalhar, a menos que você ache que pode começar a mudar coisas desse tipo.

Honestamente, você ouve histórias de guerra, mas eu realmente não achei que lugares como esse existiam mais.

    
por 01.02.2011 / 17:08
fonte