Como terminamos com o Git

Como terminamos com o Git

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


A série até agora:

  1. Como acabamos com o git
  2. Anatomia git

É fácil supor que apenas uma pequena fração dos desenvolvedores de hoje teve a chance de experimentar o que estava escrevendo código na década de 1990 ou mesmo no início de 2000. Em muitos casos, cada desenvolvedor costumava escrever código em sua própria máquina e então mesclá-lo manualmente com outras versões possivelmente gerenciadas por colegas de equipe. Manter um histórico limpo e claro das diferentes versões do código era, na maior parte, um sonho inatingível. Foi definitivamente uma abordagem bastante ingênua, mas bastante comum também. Não duraria muito, entretanto.

Neste artigo, examinarei a motivação que em duas décadas trouxe a criação de uma série de sistemas de controle de origem até o Git – o padrão universal nos dias de hoje.

Um pouco de história

Desde os primeiros dias do desenvolvimento de software, aqueles que tinham que produzir bases de código grandes e sólidas, como os componentes de um sistema operacional como o Unix, sentiram a necessidade de um sistema de controle que fosse capaz de rastrear todas as mudanças feitas ao longo do tempo. Historicamente, a primeira tentativa de construir tal sistema de controle remonta ao início dos anos 1970, mas foi apenas uma década depois que ele se solidificou em uma ferramenta de uso comum, embora bastante limitada em funcionalidade (apenas arquivos de texto individuais rastreados) e usabilidade (apenas usuários únicos).

Os primeiros sistemas centralizados de controle de código-fonte surgiram na década de 1990 e o Perforce foi o mais popular deles. O Perforce era amplamente usado no Google e era o padrão de fato usado pela maioria das empresas nos anos da bolha da Internet. Então veio o Subversion, o produto que introduziu recursos comparáveis ​​aos que temos em ferramentas modernas hoje. O Subversion estendeu os recursos de rastreamento para arquivos não-texto e, mais importante, mudou o foco do rastreamento do arquivo individual para o diretório individual. Isso permitiu o rastreamento de todas as operações de arquivo, incluindo renomeações, movimentos e exclusões.

Do lado da Microsoft, a história dos sistemas de controle de origem é curiosa e vale a pena dar uma olhada. A Microsoft tinha o SourceSafe – seu primeiro sistema de controle de origem – na década de 1990. Tecnicamente, era um produto desenvolvido originalmente por outra empresa que a Microsoft acabou de comprar. A Microsoft manteve o controle sobre o desenvolvimento do SourceSafe apenas para a plataforma Windows e delegou o desenvolvimento do produto para Mac e Unix a outras empresas. Por muitos anos, SourceSafe foi apenas um sistema de controle de fonte local e não projetado especificamente para um ambiente multiusuário. Apenas em seu lançamento final (datado de 2005), SourceSafe se tornou um produto que era capaz de funcionar em um modo cliente / servidor – definitivamente tarde demais. Curiosamente, muito poucas equipes de desenvolvimento dentro da Microsoft já usaram SourceSafe para suas próprias atividades. A maioria das equipes optou por uma versão personalizada do produto Perforce chamada SourceDepot.

Em 2004, a mesma Microsoft, entretanto, lançou um novo produto de controle de origem – Team Foundation Server (TFS) – vendido como parte do Visual Studio Team Systems, um produto de gerenciamento de ciclo de vida maior. O aspecto mais relevante do TFS era a forte integração com o ambiente do Visual Studio, que permitia aos desenvolvedores verificar a entrada e a saída de seu código no local. Além disso, o TFS introduziu suporte para rastreamento de bugs, itens de trabalho e testes automatizados.

Leia Também  Pessoal da União Europeia: Querem participar do Mastering Index Tuning?

De certa forma, a versão inicial do TFS foi a última de uma era final. A nova era foi a era dos sistemas de controle de origem distribuída.

Controle de código-fonte distribuído

A principal diferença entre uma plataforma de controle de código-fonte distribuída e centralizada é a moeda que os usuários de ambos os sistemas trocam com o servidor principal. Em um sistema centralizado e antigo, a moeda é a lista de alterações feitas localmente. Em um cenário distribuído, em vez disso, a moeda é todo o repositório de código. A imagem abaixo mostra a arquitetura de um sistema de controle de fonte centralizado.

Como você pode ver, vários usuários baixam as atualizações mais recentes de forma autônoma do servidor, depois trabalham nisso localmente em suas máquinas e, em algum ponto, eles as confirmam de volta para o servidor. Em um cenário distribuído, há uma camada adicional de código e dados no meio. Aqui está o diagrama arquitetônico de um sistema de controle de código-fonte distribuído.

Como terminamos com o Git 3

Os usuários ativos possuem um repositório local e podem compartilhá-lo com o servidor e / ou com outros usuários individuais. Dito de outra forma, o sistema distribuído permite que os desenvolvedores compartilhem código entre nós de uma rede distribuída de repositórios. Em cada máquina, o repositório de código local é atualizado por meio dos comandos update e commit. A sincronização com o servidor principal, em vez disso, passa pelo par de comandos pull e push.

A abordagem distribuída é o mainstream hoje graças ao Git, e é ainda mais interessante rastrear como exatamente o Git surgiu e por quê.

O Nascimento do Git

Como você deve saber, o Git foi escrito por Linus Torvalds por volta de 2005. Por muitos anos, a comunidade de contribuidores do kernel do Linux não usava nenhum sistema de controle de versão. Para eles, o procedimento de confirmação típico era assim:

  1. Postar alterações em uma lista de e-mails específica
  2. Faça com que Linus em pessoa aprove e aplique as alterações em sua própria árvore de origem
  3. Aguarde o verde para baixar qualquer nova árvore de origem validada pelo Linus

Funcionou de algumas maneiras, mas patches específicos eram indistinguíveis um do outro, e as mudanças eram detectáveis ​​apenas por meio de uma diferença gigante entre duas versões consecutivas da árvore de código-fonte principal. Em 2002, quando essa forma de trabalhar não era mais sustentável, Linus surpreendentemente escolheu um produto de controle de versão comercial – BitKeeper – em vez de uma variedade de ferramentas gratuitas que fazem o mesmo trabalho.

Torvalds justificou a escolha com a vantagem que, em termos de recursos, o BitKeeper poderia dar aos concorrentes. O BitKeeper era um sistema de controle de código-fonte distribuído cujo fluxo de trabalho era perfeito para o fluxo de trabalho do grupo do kernel. Em segundo lugar, o BitKeeper tornou ridiculamente simples bifurcar e mesclar até mesmo grandes repositórios de código. A combinação desses dois fatores foi a razão por trás de uma escolha estranha. Com o BitKeeper, na verdade, pequenos grupos selecionados de desenvolvedores confiáveis ​​poderiam trabalhar e sincronizar de forma autônoma e enviar para a Linus apenas o resultado final para integração de uma maneira totalmente confiável. Torvalds, porém, conseguiu obter uma edição gratuita da comunidade do BitKeeper em troca de algumas restrições destinadas principalmente a proteger a propriedade intelectual do BitMover – a empresa por trás do produto.

Leia Também  Uniões não-Equi no SQL Server

Nos três anos seguintes, membros proeminentes da comunidade Linux trabalharam duro para criar uma ferramenta de controle de código-fonte distribuída totalmente nova que pudesse substituir o BitKeeper. Nenhum deles, entretanto, obteve feedback suficiente de Torvalds para ir direto ao ponto que poderia tornar a nova ferramenta tecnicamente superior ao BitKeeper. Então, em 2005, de repente, tudo mudou e por um motivo completamente diferente. Como uma reação severa a uma tentativa documentada de engenharia reversa do código-fonte, o BitMover descontinuou o uso gratuito do BitKeeper para a equipe de desenvolvimento do kernel Linux.

Em questão de meses, em meados de 2005, Torvalds criou o mecanismo Git e o tornou rápido, forte e sólido o suficiente para ser adequado para sustentar o desenvolvimento de um projeto grande e amplamente distribuído como o kernel Linux. Depois disso, Torvalds passou todo o desenvolvimento do Git para Junio ​​Hamano e voltou a se concentrar no desenvolvimento do kernel Linux.

A filosofia do Git

No início, Git parecia bastante estranho aos olhos de muitos desenvolvedores Linux. Foi vendido como o sistema de controle de código-fonte preferido, mas não se parecia com nenhum dos sistemas de controle de código-fonte mais populares da época. Em particular, parecia diferente em um aspecto principal. Em vez de armazenar o delta entre as versões antigas e novas do mesmo arquivo (também conhecido como patches), o Git armazenava todo o arquivo atualizado lado a lado com uma cópia do arquivo original sendo modificado.

Essa abordagem incomum era estritamente funcional para o objetivo principal dos Torvalds: mantê-lo incrivelmente rápido! Ter apenas que copiar e / ou substituir arquivos no repositório de destino, de fato, permite que o Git manipule bifurcações, mesclagens e gere patches rapidamente. As operações originais que Torvalds planejou – muito de baixo nível e orientadas a arquivos – foram abstraídas por Hamano ao longo do tempo. O resultado é o Git como o conhecemos hoje – o sistema de controle de versão distribuída padrão de fato para rastrear alterações no código-fonte. O que torna o Git bastante único no cenário dos sistemas de controle de versão é que cada diretório em cada computador é um repositório com seu próprio histórico de mudanças. Em outras palavras, o Git permite que desenvolvedores individuais hospedem localmente um sistema de controle de versão completo que funciona independentemente do acesso à rede, mas pode ser opcionalmente sincronizado com um repositório remoto.

Git é um software de código aberto disponível em https://git.kernel.org/pub/scm/git/git.git/ e é distribuído sob a versão 2 da GNU General Public License. Em 2016, onze anos após o rompimento com o grupo de desenvolvimento do kernel Linux, ironicamente, o BitKeeper foi transformado em um produto de código aberto sob a licença Apache 2.0. (Veja https://www.bitkeeper.org.)

Finalmente, aqui está uma nota sobre o nome. De acordo com o dicionário Merriam-Webster, a palavra “git” indica uma pessoa tola ou inútil, mas também pode ser tomada como uma versão dialetal do verbo “get”. Aqui, no arquivo leia-me original escrito por Torvalds, ele é apresentado como o “gerenciador de informações do inferno” e o “rastreador de conteúdo estúpido”.

Leia Também  Semana gratuita de Fundamentos da Consulta de consultas: Parte 4, Melhorando a precisão da estimativa de cardinalidade

https://github.com/git/git/blob/e83c5163316f89bfbde7d9ab23ca2e25604af290/README

Git e todo o resto deles

De acordo com a Wikipedia, no momento cerca de 30 produtos diferentes estão ativamente desenvolvidos e inscritos na competição virtual pelo prêmio de “melhor sistema de controle de código-fonte”. Eles diferem em vários fatores, incluindo as plataformas suportadas, a licença pela qual são disponibilizados e o custo. Vamos ver alguns deles.

Azure DevOps. De propriedade da Microsoft, ele é executado no Windows, mas pode ser acessado como um serviço de outras plataformas. É gratuito para projetos de código aberto e como serviço para até 5 usuários. Caso contrário, ele é licenciado por meio de uma assinatura MSDN.

Mercurial. Desenvolvido por Matt Mackall, ele roda em sistemas operacionais Windows, macOS e Unix. É gratuito para uso sob a licença GNU GPL.

Hélice. Propriedade da Perforce, ele roda em sistemas operacionais Windows, macOS e Unix. Está disponível para venda por meio de licença perpétua ou assinatura.

Subversão. Criado pela Collabnet, ele roda em sistemas operacionais Windows, macOS e Unix. É gratuito para uso sob a licença Apache.

ClearCase. De propriedade da IBM Rational, ele roda em Linux, Windows, AIX, Solaris e vários outros sistemas operacionais IBM. Ele segue um modelo de preço personalizado.

CVS. Mantido por uma comunidade de desenvolvedores, não recebe novos recursos desde 2008. Funciona em Windows, macOS e sistemas operacionais semelhantes ao Unix e é gratuito para uso sob a licença GNU GPL.

Monotone. Escrito por Nathaniel Smith e Graydon Hoare, ele roda em sistemas operacionais Windows, macOS e Unix. É gratuito para uso sob a licença GNU GPL.

De um ponto de vista mais técnico, todos os sistemas de controle de código-fonte também variam no modelo que usam para implementar o repositório e lidar com a simultaneidade.

No que diz respeito ao repositório, duas são as opções principais: cliente / servidor (centralizado) e distribuído. Dos produtos listados acima, ClearCase, CVS e Subversion são cliente / servidor, enquanto Monotone e Mercurial são distribuídos. Em vez disso, o Azure DevOps e o Helix oferecem suporte a ambos os modelos de repositório.

Simultaneidade se refere à política que o produto emprega para gerenciar as alterações na cópia de trabalho do repositório. O objetivo da política é evitar edições simultâneas que podem corromper os arquivos. Uma opção é fechadura, o que significa que o acesso de gravação a qualquer arquivo é concedido apenas a um usuário em modo exclusivo. A outra opção é fundir, o que significa que os usuários ficam livres para editar os arquivos, mas recebem um aviso sempre que ocorrer um conflito. Resolver conflitos é mais uma etapa, automática ou manual. CVS, Mercurial e Monotone suportam apenas o modelo de fusão. Os outros produtos na lista acima são compatíveis com os dois modelos.

Resumo

Este é o primeiro artigo de uma nova série que visa cobrir o Git como um produto principal e o universo ao seu redor, incluindo o Github. Este artigo introdutório lançou as bases do Git e cobriu o tópico geral, e parcialmente a história, dos sistemas de controle de código-fonte e ofereceu uma rápida comparação de alternativas ao Git. No entanto, embora existam muitas alternativas, o Git é hoje o padrão de fato para rastrear alterações em arquivos em projetos de software. No próximo artigo, começaremos uma jornada em torno das operações típicas que podem ser realizadas com o Git.

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br