Este documento apresenta os conceitos e ferramentas de sistemas de controle de versão, com foco no GIT. Apresenta os principais conceitos de VCS, como repositórios, commits e ramificações. Discute as características e comandos básicos do GIT e faz uma comparação com outros sistemas como Subversion, ClearCase e Mercurial. Por fim, apresenta um estudo de caso sobre o uso do GIT em um projeto de software.
Teoria heterotrófica e autotrófica dos primeiros seres vivos..pptx
Sistemas de controle de versão
1. UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Gerência de Projetos 2013.2
Sistemas de Controle de Versão
FELIPE OLIVEIRA CARVALHO
RAMON BATISTA RAMOS
RODRIGO LOSANO FONTES CALHEIROS
WASHINGTON CAVALCANTE DA SILVA
Professor: Dr. Rogério Patrício Chagas do Nascimento
4. O que é controle de
versões?
MOTIVAÇÃO
Gerenciamento de múltiplas revisões
Documentos, projetos, software, etc.
Histórico de alterações sofridas.
Permitir consultar revisões anteriores.
Permitir comparações entre revisões.
Permitir trabalho cooperativo.
4/67
5. O que é controle de
versões?
MOTIVAÇÃO
Vários nomes:
Revision control system (RCS).
Version control system (VCS).
Source Code Management.
Source Control.
Controle de versão não
gerenciamento de software.
é exclusivo
para
5/67
6. Por que controle de
versões?
MOTIVAÇÃO
Software é algo caro de ser produzido.
Consome muito tempo.
Exige cooperação, organização, disciplina.
É importante armazenar tudo que é feito.
6/67
7. MOTIVAÇÃO
Onde é utilizado?
Sistemas de arquivos.
Suítes de escritório.
Ambientes colaborativos.
Gerenciamento de software.
Importante para qualquer desenvolvedor ou empresa de
desenvolvimento de software.
7/67
8. RECURSOS
Registro de revisões
Toda alteração realizada é registrada.
Quem, quando, o que e por quê?
Nada é perdido para sempre.
Descartar código ruim sem remorso.
Rápido acesso a revisões anteriores.
Determinar introdução de defeitos.
Manutenção de código legado.
8/67
9. RECURSOS
Auditoria
Comparação entre versões do projeto, mostrando
diferenças linha-a-linha.
Apontar desenvolvedores responsáveis por cada
trecho de código do projeto.
Automação de testes de estabilidade.
9/67
13. MODELOS
Modelos
Centralizado (cliente-servidor).
Um repositório central de revisões.
Desenvolvedores obtém cópias de trabalho do repositório
central.
Distribuído
Cada desenvolvedor tem seu repositório.
Desenvolvedores copiam repositórios e alterações de
outros desenvolvedores.
13/67
15. MODELOS
Distribuído
Vantagens:
Permite submissões particulares, off-line.
Melhor suporte a ramificação e mesclagem.
Independência da rede, mais rápido.
Desvantagens:
Estimula o isolamento de desenvolvedores.
Questões de privacidade e segurança.
15/67
18. CONCEITOS
Cópia de trabalho
Cópia do repositório em certa revisão.
Geralmente a mais recente.
Checkout (obtenção de uma cópia).
18/67
19. CONCEITOS
Cópia de trabalho
Onde ocorre o desenvolvimento.
O sistema reconhece as alterações feitas.
Algumas operações devem ser explícitas.
Adição, remoção, cópia de arquivos.
19/67
26. GIT
HISTÓRICO
Até 2002 as mudanças no kernel do Linux eram
repassadas a partir de patches e arquivos compactados.
A partir de 2002 passou-se a utilizar o Sistema de
controle de versões proprietário chamado BitKeeper,
fornecido gratuitamente para a comunidade do Linux.
Em 2005, a empresa dona do BitKeeper revogou a licença
gratuita do software e então este deixou de ser uma
solução viável para a comunidade Linux.
Linus Torvalds (criador do Linux) decidiu então criar um
sistema de controle de versão próprio que fosse livre e
gratuito, inspirado no BitKeeper. Nascia então o GIT.
26/67
27. GIT
CARACTERÍSTICAS:
Facilitar o desenvolvimento distribuído;
• Permitir que se desenvolva em paralelo, de forma independente em
repositórios locais, sem constante sincronização com um repositório
central.
Escalável para suportar milhares de desenvolvedores;
• Lidar corretamente com milhares de desenvolvedores em um projeto.
Execução rápida e eficiente;
Manter integridade e confiabilidade;
• Utilização de hash SHA-1.
Garantia de auditoria;
• Saber quem fez o que, mantendo um registro de todas as ações.
Imutabilidade;
• Garantir que todos os objetos GIT são imutáveis, ou seja, não se
alteram.
27/67
28. GIT
CARACTERÍSTICAS:
Transações atômicas;
• Ou a transação é totalmente efetivada ou nada é feito.
Suporte e estímulo ao desenvolvimento em branches;
Repositórios completos;
• Cada repositório local tem uma cópia de tudo que já foi feito.
Design interno limpo;
Ser livre.
28/67
29. GIT
CONCEITOS:
Repositórios.
• Bases de dados contendo todas as informações necessárias para
manter e gerenciar as revisões e o histórico de um projeto.
Tipos de Objetos GIT:
• Blobs (Binary Large Objects).
◦ Cada versão de um arquivo é representado como um blob.
• Trees.
◦ Equivale a um diretório, contendo uma lista de arquivos. Descreve o estado
dessa árvore de diretório.
• Commits.
◦ Faz a ligação entre as árvores junto com um histórico.
• Tags.
◦ Adiciona um texto compreensível a um objeto (geralmente um commit).
29/67
33. GIT
Comandos Básicos:
git config user.name “Nome“
• Configura o nome de usuário.
git config user.email “nome@email.com".
• Configura o e-mail.
git init
• Inicializa um repositório GIT vazio.
git status
• Mostra o status da árvore de trabalho atual.
git add <arquivo>
• Adiciona o arquivo ao Staging do GIT.
git rm <arquivo>
• Remove um arquivo não versionado do Staging do GIT.
33/67
34. GIT
Comandos Básicos:
git reset HEAD <arquivo>
• Remove arquivos versionados e modificados do Staging.
git commit –m <mensagem>
• Arquivos que foram adicionados ao Staging são “commitados”, ou seja, enviados ao
repositório local do GIT.
git reset --hard <hash>
• Volta a área de trabalho para o commit com o hash <hash>.
git branch
• Lista, cria ou deleta branches.
git log
• Mostra os logs dos commits.
34/67
35. GIT
Comandos Básicos:
git clone
• Clona (copia) um repositório em um novo diretório.
git push
• Envia o commit local para o repositório remoto.
git pull
• Atualiza a área de trabalho local a partir de um repositório remoto.
git fetch
• Faz download dos objetos remotos.
git tag
• Cria, lista, deleta ou verifica tags.
35/67
43. Subversion X Git
Subversion
Git
Repositório centralizado
Repositório distribuído
Baixo desempenho
Alto desempenho
Cada cliente possui uma cópia do projeto
Cada cliente possui uma cópia completa
do controle de versão do projeto
podendo assim distribuir o controle de
versão para outros clientes.
Sincronismo com o repositório
dependente do servidor.
Sincronismo com o repositório
independente do servidor.
43/67
45. ClearCase
Solução de gerenciamento de configuração da
família Rational da IBM.
Controle de versão.
Gerenciamento de área de trabalho.
Suporte para desenvolvimento paralelo.
Segurança de IP efetiva.
Auditoria de compilação.
45/67
46. ClearCase
Solução paga.
Grande poder de gerenciamento.
Solução poderosa e flexível.
Pequenas equipes.
Grandes equipes geograficamente distribuídas.
46/67
48. Mercurial
Semelhante ao Git, o Mercurial se enquadra em
um controle de versão distribuído.
É semelhante também por ser um software livre.
Também é compatível com diversas plataformas.
48/67
49. Mercurial
Usado em grandes projetos como:
Google Code.
Python.
Java (OpenJDK).
Mozilla.
Netbeans (IDE).
OpenSolaris.
49/67
50. Mercurial
Existem mais semelhanças entre o Mercurial e o
Git que diferenças.
A escolha por algum dos dois em um projeto chega
a ser subjetiva.
50/67
58. Estudo de Caso
A natureza descentralizada do GIT facilita a gestão
de projetos que têm várias equipes de
desenvolvimento.
Lida muito bem com colaboração de vários grupos
de trabalhos no mesmo projeto. Essa característica
permite o desenvolvimento de vários fluxos de
trabalho.
58/67
59. Estudo de Caso
O fluxo de desenvolvimento é iniciado com o
cadastro de uma demanda no sistema de controle
de demandas adotado, o JIRA.
No JIRA, a palavra “issue” significa “demanda”.
59/67
60. Estudo de Caso
Nunca, jamais submeta um commit no branch
master.
Submeter commits no branch master impede que
o usuário trabalhe em mais de uma issue ao
mesmo tempo.
O branch master, no repositório central, é
configurado para receber commits somente dos
gestores do projeto ou revisores de commits.
60/67
61. Estudo de Caso
O colaborador terá de baixar o projeto para um
repositório local (git clone).
Supondo que uma issue de nome “pje 123” seja
aberta. O responsável pelo desenvolvimento deve
criar um branch de nome “pje 123” e submeter os
commits nele.
61/67
62. Estudo de Caso
Uma vez concluído, o desenvolvedor irá submeter
o código ao servidor de origem (git push).
Os commits do PJe devem possuir comentários.
62/67
63. Estudo de Caso
Após a submissão do código, o desenvolvedor terá
de abrir uma solicitação de merge de código
através do GitLab (interface de gestão do GIT)
Antes de ser integrada ao master do projeto, esta
solicitação será analisada pelos revisores de
commit.
63/67
64. Estudo de Caso
Antes de iniciar o desenvolvimento da próxima
issue, é aconselhável ter a última versão do master
para evitar conflitos durante a reintegração do
código (git pull).
64/67
66. Conclusão
Sistemas de controle de versão são essenciais no
desenvolvimento de projetos de software.
São essenciais para a gerência de software.
66/67
67. Referências
LOELIGER, Jon; MCCULLOUGH, Matthew. Version
Control with Git. O'Reilly Media, Inc., 2009.
Comandos Básicos do GIT, disponível em
<http://blog.gustavohenrique.net/2011/03/coman
dos-basicos-do-git/>, acessado em janeiro de 2014.
67/67