O documento discute o sistema de controle de versão distribuído Git, explicando como ele funciona de forma rápida e segura com múltiplos backups offline, e fornece links para aprender mais sobre o Git.
Boa tarde! Estou aqui hoje para bater um papo sobre controle de versão distribuído, mais especificamente, sobre o GIT...\n
Antes de mais nada, deixe eu me apresentar....\n
\n
De brincadeira, arrisco umas notas por aí...\n
e pra viver sou analista de sistemas do SERPRO e trabalho na equipe responsável pela manutenção e evolução do Framework Demoiselle. Mas isso é outra história. O papo aqui é outro...\n
Agora chega de falar de mim. Vamos ao que interessa e falar sobre controle de versão...\n
Quem trabalha com código fonte provavelmente utiliza isso diariamente. ClearCase, Perforce, CVS e sua (evolução?) Subversion são alguns exemplos. Se você não trabalha assim, então... deixa pra lá. E o GIT? Bem, o GIT é sistema de controle de versão distribuído...\n
... Open source ...\n
... projetado e desenvolvido, inicialmente, para o desenvolvimento do kernel do Linux. Um dos grandes motivadores para a sua criação foi a insatisfação de Linus Torvalds com os sistemas de controle de versão existentes. Por isso, algumas premissas básicas foram definidas como, por exemplo....\n
... tomar o CVS como exemplo do que NÃO fazer. Na dúvida, faça exatamente o oposto. Segundo ele, nos primeiros 10 anos de desenvolvimento do kernel, a colaboração era feita através de patches, que é algo muito superior ao CVS. A preocupação com a colaboração deu origem a outra premissa...\n
... que tivesse suporte à distribuição. Nesse modelo, acaba aquela história “Commit access”. Não é preciso solicitar autorização para ninguém para dar commit no seu repositório. Daqui a pouco vocês vão entender porque falei SEU repositório. Além disso, existe uma série de outros benefícios como, por exemplo, a existência de ciclos concorrentes de desenvolvimento/teste/release.\n
Fato, precisaria ser algo que possibilitasse uma forte garantia contra dados corrompidos, seja de forma acidental ou intencional. As três características citadas até aqui já eliminavam quase todas as soluções existentes. Mas o golpe de misericórdia foi a última...\n
... alta performance. Este realmente é o calcanhar de Aquiles da maioria dos sistemas de controle de versão. O fato é que qualquer coisa que dependa de tráfego de rede será lenta. A performance não deve ser considerado como algo secundário: afeta como você trabalha e a qualidade do seu trabalho. Imagine esperar 30 segundos para baixar um código simples...\n
O mais legal em relação aos SCM’s distribuídos, como o GIT, é o fato deles serem DISTRIBUÍDOS. Isso significa que, ao invés de fazer o checkout de um código do repositório, você irá guardar todo o repositório localmente. Isso é feito através de um conceito chamado de...\n
... clonagem do repositório. Dessa forma, não há necessidade de submeter todo e qualquer commit ao servidor. CONTROLE DE VERSÃO NÃO É BACKUP. Algo só será submetido ao repositório central quando for de interesse para os outros colaboradores do projeto. Tudo o que você faria remotamente, como a utilização de branches, por exemplo, pode ser feito localmente.\n
Uma vez feito o clone, você terá uma estrutura como essa. Lembra quando falei SEU REPOSITÓRIO? Pois é, era sobre isso que eu falava. Nessa estrutura, você faz miséria: branches, merge... tudo isso localmente...\n
\n
\n
\n
Alguns sites que oferecem hospedagem gratuita para repositórios GIT.\n
Alguns sites que oferecem hospedagem gratuita para repositórios GIT.\n
Alguns sites que oferecem hospedagem gratuita para repositórios GIT.\n
Alguns sites que oferecem hospedagem gratuita para repositórios GIT.\n
Alguns sites que oferecem hospedagem gratuita para repositórios GIT.\n
Alguns sites que oferecem hospedagem gratuita para repositórios GIT.\n