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.

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

2. Agenda

Conceitos gerais;

GIT;

Comparação do GIT com outros SCV;

Estudo de Caso;

Conclusão.
2/67

3. Agenda

Conceitos gerais;

GIT;

Comparação do GIT com outros SCV;

Estudo de Caso;

Conclusão.
3/67

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

10. RECURSOS
Ramificações
Múltiplas linhas de desenvolvimento dentro do
mesmo projeto.
Permite divergência
desenvolvimento.
e
“reconvergência”
do
10/67

11. RECURSOS
Trabalho cooperativo
Vários desenvolvedores trabalhando sobre o
mesmo projeto.
Mescla
das
alterações
dos
desenvolvedores ou ramificações.
diversos
11/67

12. RECURSOS
Segurança
Autenticação criptográfica de histórico.
Controle de acesso sobre o repositório.
Cópias de segurança (backup).
12/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

14. Centralizado (clienteservidor)
MODELOS
Vantagens:
 Controle de acesso.
 Cópia de segurança.
 Controle de qualidade.
Desvantagens:
 Dependência do repositório central.
 Ponto único de falha.
14/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

16. CONCEITOS
Repositório
Núcleo do controle de versões.
Possui uma “linha do tempo” embutida.
 Coletânea de revisões do projeto
16/67

17. CONCEITOS
Repositório
Revisão/Versão.
 Estado em um determinado instante.
 Imutável após criada.
17/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

20. Cópia de trabalho
CONCEITOS
Submissão (commit).
 Alterações são registradas em uma nova revisão do
repositório.
20/67

21. CONCEITOS
Ramificações (branches)
Linhas alternativas de desenvolvimento.
 Explícitas.
 Implícitas.
21/67

22. CONCEITOS
Mesclagem (merge)
Reintegração de ramificações.
 Em grande parte é automatizado.
 Conflitos podem ocorrer.
O desenvolvedor pode precisar interagir.
22/67

23. CONCEITOS
Rótulos (tags)
Nomes atribuídos a revisões.
23/67

24. Sistemas de Controle de
Versão
PRODUTOS
Centralizado
Aberto
Distribuído
CVS,
GIT,
OpenCVS,
Proprietário
Subversion,
Vesta
Mercurial
ClearCase,
SourceSafe,
BitKeeper,
Bazaar,
TeamWare
Serena
24/67

25. Agenda

Conceitos gerais;

GIT;

Comparação do GIT com outros SCV;

Estudo de Caso;

Conclusão.
25/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

30. GIT
30/67

31. GIT
31/67

32. GIT
Áreas de trabalho do GIT:
32/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

36. GIT
36/67

37. Agenda

Conceitos gerais;

GIT;

Comparação do GIT com outros SCV;

Estudo de Caso;

Conclusão.
37/67

38. Subversion
38/67

39. Subversion
Fundado pela Apache.
Licença de Software livre.
Lançada a versão 1.0 em 2004.
Substituto moderno do CVS.
39/67

40. Subversion
Sistema de controle de versão centralizado.
Um dos sistemas de controle mais utilizados.
Facilidade no uso.
40/67

41. Subversion
41/67

42. Subversion
42/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

44. ClearCase
44/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

47. Mercurial
47/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

51. Outros Sistemas de
controle de versão
51/67

52. Agenda

Conceitos gerais;

GIT;

Comparação do GIT com outros SCV;

Estudo de Caso;

Conclusão.
52/67

53. Estudo de Caso
53/67

54. Estudo de Caso
54/67

55. Estudo de Caso
55/67

56. Estudo de Caso
56/67

57. Estudo de Caso
57/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

65. Agenda

Conceitos gerais;

GIT;

Comparação do GIT com outros SCV;

Estudo de Caso;

Conclusão.
65/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