Introdução ao Git
Laboratório de Programação
Luísa Lima, Pedro Vasconcelos, DCC/FCUP
Março 2015
Porquê controlo de versões?
Um sistema de controlo de versões (VCS) é um ferramenta integrada que possibilita
•
•
•
•
•
•
arquivo e recuperação de ficheiros
“undo” de curto e longo prazo
rastreamento de alterações
sincronização entre computadores
colaboração entre programadores
experimentação (“sandboxing”)
. . . requirindo o mínimo esforço.
Controlo de Versões Local
Sistemas de controlo de versões convencionais permitem alguns destes benefícios
registando mudanças de ficheiros numa base de dados local.
1
Qualquer ficheiro pode ser reconstruído a partir das mudanças registadas na
base de dados.
Controlo de Versões Centralizado
Para permitir sincronização e colaboração, a base de dados pode ser guardada
num servidor central; todos os colaboradores utilizam a mesma base de dados.
Problemas: um ponto único de falha, não permite trabalhar offline.
Controlo de Versões Distribuído (1)
Os sistemas de controlo de versões distribuidos (DVCSs) ultrapassam os problemas de centralização mantendo uma cópia completa da base de dados em
cada posto de trabalho.
Este modelo de VCS é simultamenente mais simples e poderoso que o modelo
centralizado.
2
Controlo de Versões Distribuído (2)
Vantagens dos sistemas distribuídos
• todas as cópias do repositório contêm o historial completo (e não apenas
o seu estado atual)
• permite trabalhar localmente registando alterações mesmo sem acesso
a rede
• facilita a recuperação de dados (não há um ponto único de falha)
• facilita a introdução de mudanças experimentais separadas das estáveis
(“branching”)
O que é o Git
•
•
•
•
Sistema de controle de versões distribuído
Desenvolvido desde 2005 para controle de versões do kernel Linux
Também muito usado em projetos open-source (github.com)
Características:
–
–
–
–
–
rapidez
design simples
adequado a projectos grandes
suporte para desenvolvimento não linear (“branching”)
completamente distribuído
3
O Git dá-te super-poderes!
Utilizar git é um método de trabalho valioso:
• garantimos a integridade dos nossos ficheiros
(diga adeus às pen-drives para transportar ficheiros entre casa e trabalho)
• usando um repositório remoto, temos sempre um backup caso algo
corra mal
• permite experimentar e explorar sem termos medo das consequências
(dá sempre para voltar atrás caso seja necessário)
• as mensagens de commits permitem-nos rever os motivos das alterações
Como funciona
• cada repositório rastreia um conjunto de ficheiros e diretórios (um “mini”
sistema de ficheiros)
• podem mudar ao longo do tempo:
– acrescentar/remover ficheiros
– editar o conteúdo
• quando o utilizador regista uma modificação (commit):
– guarda o estado atual de todos os ficheiros marcados (snapshot)
– para os ficheiros não modificados: guarda apenas uma referência para
o estado anterior
• um repositório Git é uma sequência de “snapshots”
Git Básico - Fluxo de trabalho
Três fases:
1. Modify: modificar os ficheiros no directório de trabalho.
2. Stage: adicionar snapshots dos ficheiros à “área de estágio” (staging area).
3. Commit: registar esse snapshots na base de dados do Git juntamente
com uma mensagem de arquivo.
4
Git Básico - Operações locais
Git Básico - Commit
• uma “imagem” dos ficheiros tal como estavam quando estagiados;
• uma mensagem de arquivo que descreve a alteração efetuada;
• meta-informação do autor e data.
Qualquer commit pode ser inspecionado e recuperado se assim quisermos.
Git Básico - Ciclo de Vida
Os ficheiros no directório de trabalho podem estar em quatro estados diferentes
em relação ao commit atual.
5
Prática - Configuração inicial do Git
Antes de usar Git pela primeira vez:
Escolher a sua identidade
git config --global user.name "John Doe"
git config --global user.email [email protected]
Mais configurações (opcionais)
git config --list
Obter ajuda
git help <verb>
Prática - Inicializar um repositório local
cd my_repo
git init
• inicializa um diretório my_repo/.git
• o repositório começa vazio: temos de adicionar ficheiros e/ou diretórios
6
Prática - Adicionar ficheiros
git add <fich1>
git add <fich2>
Tambem podemos adicionar vários ficheiros de uma só vez:
git add <fich1> <fich2>
NB: os ficheiros ficam na área de “estágio” — temos de fazer um commit para
os registar na base de dados do Git.
Prática - Primeiro Commit
git commit -m "Iniciar o meu repositório"
NB: podemos também adicionar ou remover ficheiros mais tarde.
Prática - Modificar ficheiros
Podemos fazer alterações aos ficheiros usando um qualquer editor. Quando
estivermos devemos devemos:
1. adicionar os ficheiros à àrea de estágio
2. registar um commit com uma mensagem descritiva.
emacs
# editar fich1 fich2
...
git add fich1 fich2
git commit -m <mensagem>
Prática - Mudar nomes
Podemos usar git mv para mudar o nome de um ficheiro e preservar a história
de alterações.
git mv <fich-atual> <fich-novo>
7
Git Básico - Repositórios remotos
Em Git todos os repositórios são iguais (i.e. têm a mesma importância).
Um repositório remoto é apenas uma ligação para um outro diretório Git.
Prática - Começar a usar um servidor remoto
Para usar um repositório já inicializado (i.e. com um diretório Git) basta fazer
clone do repositório:
git clone <caminho-para-repositório>
• podemos referir um servidor remoto usando https://... ou ssh://...
• obtemos uma cópia local completa do repositório, que podemos modificar
livremente
Prática - Usar um repositório remoto
Podemos fazer alterações aos ficheiros da cópia local tal como num repositório
local.
emacs
# editar fich1
...
git add fich1
git commit -m <mensagem>
Para já este commit existe apenas na cópia local do repositório — nada foi
enviado ao servidor remoto!
Prática - Enviar modificações
Para enviar os seus commits locais para o repositório remoto devemos usar
o comando push.
git push
8
Prática - Receber modificações
Para receber alterações que outros tenham enviado ao repositório remoto usamos
pull:
git pull
Este comando pede e aplica commits remotos.
Como coordenar com colaboradores
Há várias formas de usar o git com repositórios remotos:
• com um branch único partilhado por todos os colaboradores — semelhante
ao uso de um repositório centralizado (CVS, SVN );
• com branches distintos para desenvolvimento separado (caso particular:
gitflow).
Nesta cadeira
Sugerimos usar o git de forma semelhante ao SVN :
• com um repositório central, que serve como o único ponto de sincronismo
para todas as mudanças;
• com um único branch (master).
Gitlab — repositório central
• Alternativa “self-hosted” ao github
• Disponível em https://gitlab01.alunos.dcc.fc.up.pt.
Prática - Sumário
Sumário de um fluxo de trabalho mínimo com Git:
•
•
•
•
•
clone de um repositório remoto
add os ficheiros alterados à àrea de estágio
commit para registar alterações no diretório Git
push para enviar alterações ao repositório remoto
pull para receber alterações do repositório remoto
9
That’s all, folks
E é apenas isto. Vamos ver alguns exemplos.
Nota: alguns cuidados a ter
• Fazer bons commits:
– use o git add para juntar apenas as alterações relacionadas
– escolha boas mensagens: o porquê do commit, não a descrição dos
ficheiros (desnecessária!)
• Ter em atenção que, se alterarmos a história do repositório de forma
descuidada, não estamos apenas a afectar-nos mas também aos nossos
colegas de trabalho.
Maus exemplos de mensagens
git
git
git
git
git
git
git
git
commit
commit
commit
commit
commit
commit
commit
commit
-m
-m
-m
-m
-m
-m
-m
-m
"Últimas alterações."
"Alterações do Pedro."
"Adiciona o Jogador.java."
"Alterações no Jogador.java."
"Adiciona cenas."
"Revision"
"Blablabla"
"WTF WTF WTF"
Bons exemplos de mensagens
git commit -m "Resolve o bug do premio."
git commit -m "Remove duplicação de código."
git commit -m "Acrescenta a contagem
da pontuacao."
Referências
•
•
•
•
Git Community Book
Pro Git
Git Reference
Github
10
• Atlassian git tutorial
• Git immersion
GUIs para Git
• Sourcetree (MacOS, Windows)
• Giggle (Linux)
A obrigatória referência ao XKCD
11