sistemas de controle de versão
Post on 25-May-2015
403 Views
Preview:
TRANSCRIPT
Sistemas de Controle de Versão
UNIVERSIDADE FEDERAL DE SERGIPECENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃOGerência de Projetos 2013.2
FELIPE OLIVEIRA CARVALHORAMON BATISTA RAMOS
RODRIGO LOSANO FONTES CALHEIROSWASHINGTON CAVALCANTE DA SILVA
Professor: Dr. Rogério Patrício Chagas do Nascimento
2/67
Agenda Conceitos gerais; GIT; Comparação do GIT com outros SCV; Estudo de Caso; Conclusão.
3/67
Agenda Conceitos gerais; GIT; Comparação do GIT com outros SCV; Estudo de Caso; Conclusão.
4/67
O que é controle de versões?Gerenciamento de múltiplas revisõesDocumentos, projetos, software, etc.Histórico de alterações sofridas.Permitir consultar revisões anteriores.Permitir comparações entre revisões.Permitir trabalho cooperativo.
MOTIVAÇÃO
5/67
O que é controle de versões?Vários nomes:Revision control system (RCS).Version control system (VCS). Source Code Management. Source Control.
Controle de versão não é exclusivo para gerenciamento de software.
MOTIVAÇÃO
6/67
Por que controle de versões?Software é algo caro de ser produzido.Consome muito tempo.Exige cooperação, organização, disciplina.É importante armazenar tudo que é feito.
MOTIVAÇÃO
7/67
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.
MOTIVAÇÃO
8/67
Registro de revisõesToda 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.
RECURSOS
9/67
AuditoriaComparaçã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.
RECURSOS
10/67
RamificaçõesMúltiplas linhas de desenvolvimento dentro do mesmo projeto.Permite divergência e “reconvergência” do desenvolvimento.
RECURSOS
11/67
Trabalho cooperativoVários desenvolvedores trabalhando sobre o mesmo projeto.Mescla das alterações dos diversos desenvolvedores ou ramificações.
RECURSOS
12/67
SegurançaAutenticação criptográfica de histórico.Controle de acesso sobre o repositório.Cópias de segurança (backup).
RECURSOS
13/67
ModelosCentralizado (cliente-servidor).Um repositório central de revisões.Desenvolvedores obtém cópias de trabalho do repositório
central.
DistribuídoCada desenvolvedor tem seu repositório.Desenvolvedores copiam repositórios e alterações de
outros desenvolvedores.
MODELOS
14/67
Centralizado (cliente-servidor)Vantagens:Controle de acesso.Cópia de segurança.Controle de qualidade.
Desvantagens:Dependência do repositório central.Ponto único de falha.
MODELOS
15/67
DistribuídoVantagens: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.
MODELOS
16/67
RepositórioNúcleo do controle de versões.
Possui uma “linha do tempo” embutida.Coletânea de revisões do projeto
CONCEITOS
17/67
RepositórioRevisão/Versão.Estado em um determinado instante. Imutável após criada.
CONCEITOS
18/67
Cópia de trabalhoCópia do repositório em certa revisão.Geralmente a mais recente.Checkout (obtenção de uma cópia).
CONCEITOS
19/67
Cópia de trabalhoOnde 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.
CONCEITOS
20/67
Cópia de trabalhoSubmissão (commit).Alterações são registradas em uma nova revisão do
repositório.
CONCEITOS
21/67
Ramificações (branches)Linhas alternativas de desenvolvimento.Explícitas. Implícitas.
CONCEITOS
22/67
Mesclagem (merge)Reintegração de ramificações.Em grande parte é automatizado.Conflitos podem ocorrer.
O desenvolvedor pode precisar interagir.
CONCEITOS
23/67
Rótulos (tags)Nomes atribuídos a revisões.
CONCEITOS
24/67
Sistemas de Controle de Versão
PRODUTOS
Centralizado Distribuído
Aberto Subversion, CVS,
OpenCVS, Vesta
GIT, Bazaar,
Mercurial
Proprietário ClearCase, SourceSafe,
Serena
BitKeeper, TeamWare
25/67
Agenda Conceitos gerais; GIT; Comparação do GIT com outros SCV; Estudo de Caso; Conclusão.
26/67
GIT HISTÓRICOAté 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.
27/67
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.
28/67
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.
29/67
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).
30/67
GIT
31/67
GIT
32/67
GITÁreas de trabalho do GIT:
33/67
GITComandos 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.
34/67
GITComandos 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.
35/67
GITComandos 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.
36/67
GIT
37/67
Agenda Conceitos gerais; GIT; Comparação do GIT com outros SCV; Estudo de Caso; Conclusão.
38/67
Subversion
39/67
SubversionFundado pela Apache.Licença de Software livre.Lançada a versão 1.0 em 2004.Substituto moderno do CVS.
40/67
SubversionSistema de controle de versão centralizado.Um dos sistemas de controle mais utilizados.Facilidade no uso.
41/67
Subversion
42/67
Subversion
43/67
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.
44/67
ClearCase
45/67
ClearCaseSoluçã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.
46/67
ClearCaseSolução paga.Grande poder de gerenciamento.Solução poderosa e flexível.Pequenas equipes.Grandes equipes geograficamente distribuídas.
47/67
Mercurial
48/67
MercurialSemelhante 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.
49/67
MercurialUsado em grandes projetos como:Google Code.Python. Java (OpenJDK).Mozilla.Netbeans (IDE).OpenSolaris.
50/67
MercurialExistem 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.
51/67
Outros Sistemas de controle de versão
52/67
Agenda Conceitos gerais; GIT; Comparação do GIT com outros SCV; Estudo de Caso; Conclusão.
53/67
Estudo de Caso
54/67
Estudo de Caso
55/67
Estudo de Caso
56/67
Estudo de Caso
57/67
Estudo de Caso
58/67
Estudo de CasoA 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.
59/67
Estudo de CasoO 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”.
60/67
Estudo de CasoNunca, 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.
61/67
Estudo de CasoO 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.
62/67
Estudo de CasoUma vez concluído, o desenvolvedor irá submeter o código ao servidor de origem (git push).Os commits do PJe devem possuir comentários.
63/67
Estudo de CasoApó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.
64/67
Estudo de CasoAntes 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).
65/67
Agenda Conceitos gerais; GIT; Comparação do GIT com outros SCV; Estudo de Caso; Conclusão.
66/67
ConclusãoSistemas de controle de versão são essenciais no desenvolvimento de projetos de software.
São essenciais para a gerência de software.
67/67
ReferênciasLOELIGER, 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/comandos-basicos-do-git/>, acessado em janeiro de 2014.
top related