Como os desenvolvedores de aplicativos profissionais usam sistemas de controle de versão, como GIT e Subversion?

Eu sou um desenvolvedor iniciante e tenho me perguntado desde o início, como profissionais usam ferramentas como GIT e Subversion (não tenho um entendimento muito bom sobre essas ferramentas), para atender às necessidades de seus projetos. Se eles o usarem, como eu configuraria algo assim?

Meus aplicativos não são tão grandes e ainda não estou trabalhando em equipe, eles me ajudariam muito?

Existem perguntas neste site sobre como usar as ferramentas, mas preciso de suporte para iniciantes.

O controle de origem é onipresente - pode-se até dizer que você não pode se chamar um desenvolvedor profissional se não o estiver usando. Mesmo quando se desenvolve sozinho, o controle de origem ainda oferece alguns benefícios. No final, fornece uma história e um extenso caminho de desfazer. Também libera você para experimentar muito mais, com a certeza de que, se você não gostar da nova versão, poderá sempre voltar ao que tinha antes.

Dito isto, os fluxos de trabalho, mesmo dentro de um sistema de controle de origem como Subversion ou Git, variam imensamente de equipe para equipe. O melhor lugar para começar é provavelmente escolher um sistema de controle de origem e se familiarizar com seus fluxos de trabalho padrão (mantendo em mente que você terá que alternar fluxos de trabalho ao longo de sua vida profissional).

Para começar, eu recomendaria o Git. Sou fã do Git, mas, mais especificamente, a escolha do Git permite que você comece a trabalhar sem servidor e só configure um servidor quando isso fizer sentido para você. O Subversion, por outro lado, requer um servidor e a configuração de um servidor, embora não seja extremamente difícil, é assustadora quando você não está familiarizado com esse tipo de coisa.

Aqui está uma boa visão geral de algumas boas regras práticas para controle de origem em geral: http://scottonwriting.net/sowblog/archive/2008/11/13/163320.aspx

Ao trabalhar sozinho, você não precisa de muito fluxo de trabalho. Comprometa cedo, comprometa-se frequentemente. Se você começar a lançar versões, marque seus lançamentos. Crie ramificações para experimentos ou longos trabalhos divergentes (o Git torna isso mais barato e mais simples que o Subversion).

Os sistemas de controle de origem (SVN, Git etc.) em um nível muito simplista permitem manter o histórico de alterações dos arquivos. Isso permite que você veja como o seu código mudou ao longo do tempo e reverta as alterações que você não deseja (por exemplo, a alteração não funciona conforme o esperado, você pode reverter o código para um estado conhecido anteriormente). Isso é algo que até o desenvolvimento por conta própria se tornará inestimável para você quando você começar a usá-lo.

Assim que você estiver trabalhando com outras pessoas em uma equipe, os benefícios aumentam ainda mais, pois várias pessoas podem alterar o mesmo arquivo e, se as alterações não conflitarem (por exemplo, 2 pessoas alteram seções diferentes do arquivo), as alterações serão mescladas automaticamente. Se houver algum conflito, você poderá ver as alterações ao lado dos colegas e discutir com eles como mesclar as alterações.

Você também pode criar instantâneos da base de código (geralmente chamada de tag) ao liberar uma versão do código para poder depurar facilmente problemas, mesmo que a fonte principal tenha avançado com novos recursos que ainda não foram lançados.

Aqui estão alguns recursos úteis:

Instalando e executando o Subversion e o Tortoise SVN com o Visual Studio e .NET

Controle de versão com Subversion

Tutoriais para iniciantes

Existem ótimos tutoriais (vídeo e texto) que podem ajudá-lo a começar de um nível muito básico. O Git parece ter uma ótima abordagem para introduzir o tópico de maneira suave para iniciantes, que mostra o porquê primeiro e usa repetição, definição e gráficos para ajudá-lo a lembrar os nomes e funções dos comandos principais.

SVN

O SVN pretendia ser o CVS melhorado. O CVS (sistema de versão simultâneo) trabalhava em itens de um arquivo por vez, o SVN normalmente trabalhava em itens de um diretório ou árvore de diretórios por vez. O SVN (e o CVS ou outros sistemas) pode ser importante se você o estiver usando no trabalho, mas minha opinião é que melhoramos significativamente nosso entendimento do que é necessário para fazer o controle de origem a cada poucos anos, assim como você preferiria um modelo tardio computador, você deve preferir uma ferramenta de controle de origem do modelo atrasado. É um investimento enorme para alterar sistemas, e o histórico de código pode ser perdido, embora para muitos sistemas existam conversores que permitem migrar seu código, além de histórico e outros artefatos criados pelo sistema que está sendo aposentado.

O controle de fonte profissional atende às necessidades profissionais

Sua pergunta "Como os profissionais usam ferramentas como GIT e Subversion para atender às necessidades de seus projetos?" relaciona-se estreitamente com a pergunta "Como as equipes trabalham juntas sem se atrapalharem enquanto ainda trabalham o mais rápido possível?"

O código está mudando frequentemente com alguns desenvolvedores criando código que outros desenvolvedores usarão e com uma variedade de partes interessadas que precisam de níveis diferentes de estabilidade versus inovação. Os sistemas de controle de origem ajudam a armazenar código para uso da equipe, mantendo cada mudança no contexto com versões que mudam com o tempo e, geralmente, também com ramificações que são cópias controladas do código que servem para isolar grupos de mudanças de outros grupos de mudanças.

Reunir as coisas de novo, mesclar o trabalho de muitos membros da equipe é uma tarefa que, no SVN e em sistemas mais antigos, era centralizada e difícil. Para equipes que usam o Git, a fusão se torna mais simples e mais acessível à influência de toda a equipe, em vez de alguns especialistas. No SVN, a ramificação pode ser uma questão pessoal, mas a fusão geralmente causa impactos dolorosos na equipe, e o movimento do código de volta à linha principal pode ser doloroso da perspectiva de obter permissão, evitar quebras e o nível de esforço necessário para a tarefa .

Em um repositório de controle de origem estabelecido, os profissionais podem atender a outras necessidades, como diagnosticar problemas à causa raiz. Se havia versões do código que costumavam funcionar e problemas recém-encontrados que ocorrem na versão atual, é possível avançar e retroceder no histórico para identificar quando o problema ocorreu. No SVN, esse recurso é imaturo, mas no Git a pesquisa da última versão funcional / primeira falha é suportada por um comando chamado git bisect. O problema será causado por uma das alterações de origem entre as duas versões, o que é potencialmente um diagnóstico muito mais fácil do que uma pesquisa em toda a base de códigos.

Desculpe por divagar, espero que isso ajude você a usar o controle de origem.

Minha equipe usa um sistema de controle de versão de equipe desenvolvido em casa. (Infelizmente, o Git parece não funcionar ainda nos arquivos de origem "nativos" do IBM i). equipe VCS.

Como se costuma dizer na votação ... comprometa-se cedo, comprometa-se frequentemente. Enquanto trabalho em novos recursos, comprometo-me. Confirmo entre compilações e a cada tentativa de corrigir erros do compilador, sempre que faço alterações durante o teste e a depuração. Isso permite que seja mais simples tentar várias variações de um tema e, se necessário, voltar com facilidade, especialmente quando uma alteração é coordenada em vários arquivos.

O Git melhorou a maneira como abordo o desenvolvimento.