Slides de uma aula ministrada na disciplina de Engenharia de Software no Programa de Pós-Graduação em Ciência da Computação e Matemática Computacional sobre Git.
7. O que é?
Software para gerenciar versões de um projeto em
desenvolvimento. Muito utilizado em projetos open source.
Versionamento e Controle de versão
7
8. O que é? Versionamento e Controle de versão
● CVS (Version Control System)
● SVN (Subversion)
● GIT
8
12. Controle de versão Centralizado
Há um único repositório e
várias cópias de trabalho
que se comunicam apenas
através do repositório
central.
12
13. São vários repositórios autônomos
e independentes, um para cada
desenvolvedor. Cada repositório
possui uma área de trabalho
acoplada e as operações commit e
update acontecem localmente entre
os dois.
Controle de versão Distribuído
13
15. Depende do Projeto, podemos elencar Distribuído como o melhor por
dois principais motivos:
● Equipe com centenas de desenvolvedores. Significa que mais
processamento vai ser exigido do servidor central, piorando o
tempo de resposta;
● Equipe espalhada em diferentes filiais da empresa. Acesso
remoto ao repositório com limitações de conexão e de permissão
de escrita;
Qual o melhor? (Centralizado vs Distribuído)
15
16. ● Distribuição do processamento;
● Redundância/replicação de
repositórios;
● Possibilidades de colaboração
entre desenvolvedores.
Benefícios da versão Distribuída
16
17. Ponto de vista do desenvolvedor:
● Rapidez;
● Autonomia;
● Ramos Individuais;
● Facilidade de mesclagem.
Benefícios da versão Distribuída
17
18. Ponto de vista da Gerência:
● Confiabilidade;
● Redução do custo com
servidores.
Benefícios da versão Distribuída
18
19. ● No centralizado, os
desenvolvedores trabalham no
mesmo ramo;
● Exige mais conhecimento de
controle de versão;
● Modelo distribuído mais
complicado.
Desvantagens da versão Distribuída
19
27. Premissas de todo controle de versão
“Controlar seu código fonte deve ser uma premissa. Os
princípios a seguir servem para qualquer tipo de controle
de versão.”
27
45. git reset HEAD | [file] | [pattern]
Repor atual HEAD para o estado especificado. Volta da staging
area para working directory
45
46. git reset --hard | [commit]
Redefine o índice e a working tree. Quaisquer alterações nos
arquivos rastreados na árvore de trabalho desde <commit> são
descartadas.
46
47. git commit -m “[Mensagem]”
Registrar alterações no repositório.
47
87. Github: o maior site de hospedagem git
87
● Lançado em 2008 e é usado desde então para que
desenvolvedores possam hospedar seus projetos;
● O GitHub costuma ser o preferido entre os seus utilizadores
por oferecer também alguns recursos de redes sociais.
88. Github: o maior site de hospedagem git
88
● Ele está disponível gratuitamente, com limite de
armazenamento de 300MB;
● Para quem busca mais privacidade, o serviço oferece ainda
planos pagos.
89. Github: vantagens
89
● Pode ser usado como
portifólio;
● Integração com Git;
● Funciona como rede social;
● Possibilidade de aprender
ainda mais.
91. Github Pages
91
● O GitHub Pages é um serviço de hospedagem de site
estático projetado para hospedar suas páginas pessoais, de
organização ou de projeto diretamente de um repositório do
GitHub.
● O GitHub Pages é um serviço de hospedagem de site
estático e não suporta código do lado do servidor, como
PHP, Ruby ou Python.
92. Github Pages
92
● Cria o repositório no GitHub
● Cria e publica um branch chamado gh-pages
● Voilà
https://username.github.io/Repositorio
108. Exercícios
1. Criar um repositório;
2. Partindo do pressuposto que este repositório já exista no
GitHub, vinculá-lo ao repositório local;
3. Incluir no projeto o arquivo “index.html” e as pastas “css” (com
o arquivo “css.txt” dentro e “js” (com o arquivo “js.txt” dentro)
4. Commitar
5. Incluir no projeto a pasta “resources” com o arquivo
“nomes.txt” dentro.
6. Incorporar a nova alteração ao commit anterior;
6.1 Fazer upload das alterações; 108
109. Exercícios
7. Incluir o arquivo “readme.txt” numa nova feature do sistema.
(A versão em produção não pode ter este arquivo).
8. Incluir o arquivo “config.txt” numa nova feature do sistema.
(A versão em produção não pode ter este arquivo).
8.1 Fazer upload desta feature para que outros também
trabalhem nela.
9. Corrigir um BUG na versão em produção, a pasta “resources”
deve ser deletada. (Essa correção também tem que surtir efeito
na versão em desenvolvimento).
9.1 Fazer upload das alterações. 109
110. Exercícios
10. Fazer download das possíveis alterações
11. Finalizar as features iniciadas nos passos 7. e 8.
11.1 Fazer upload das alterações
12. Corrigir um BUG da versão em desenvolvimento (o arquivo
“readme.txt” deve se chamar “leiame.txt”).
12.1 Fazer upload das alterações
13. Deletar as pastas “css” e “js” da versão de produção.
14. Commitar.
15. Desfazer as alterações realizadas pelo passo 13.
16. Disponibilizar o sistema no GitHub Pages. 110