Este documento apresenta os conceitos básicos do sistema de controle de versão Git. Resume os principais comandos como add, commit, status, log e diff. Explica conceitos como branches, staging area e working directory. Fornece também dicas e referências sobre Git.
2. Me, Myself and I
• Nuno Machado
• ngsmo@iscte-iul.pt
• @logicB0x
• Programador : C# / .NET
• Estudante : MEI
• Membro do ACM
3. Objectivos
• Aprender os conceitos básicos de git
• Conseguir gerir um repositório
• Guardar uma “cabula” de comandos
4. Source Version Control
Central Distribuído
• Código reside no servidor.
• Programador precisa de ter ligação ao
servidor.
• Mais fácil de gerir.
• Mais difícil de efectuar “Ramos” (branches)
de desenvolvimento paralelas.
• É necessário um sistema de backup ao
código-fonte.
• Código reside na “máquina” de cada
programador.
• Programador não precisa de ter ligação ao
servidor, tem a totalidade do repositório do
seu lado.
• Mais complexo de gerir.
• Deve-se fazer “Ramos” (branches) de
desenvolvimento paralelas.
• Cada programador tem todo o código
consigo. Se houver um problema pode
pedir uma cópia a outro membro da equipa.
• Pode assumir uma arquitectura centralizada
com a partilha de um repositório especial.
5. História do git
Após divergência com o licenciamento do BitKeeper - Linus Torvalds começa o desenvolvimento do git em
2005.
É o SCM que é utilizado para o desenvolvimento do Kernel de Linux.
O sucesso de plataformas como github e bitbucket ajudaram que a adaptação de git fosse de forma
exponencial no desenvolvimento de software, principalmente em Open-Source.
7. Configurar git
Existem três níveis de configurações em git
system : configurações ao nível do sistema.
global : configurações ao nível do utilizador.
““: configurações ao nível do repositório.
As configurações ao nível do repositório rescrevem as conf. do nível
global, que por sua vez rescrevem as do gerais do sistema.
8. Configurar git
• git config --global user.name <name>
• git config --global user.email <email>
• git config --system core.editor <editor>
Nota : Podemos editar directamente os ficheiros de configuração. A sua localização
depende do sistema operativo utilizado.
Exemplos comuns :
10. Conceitos git
Em git temos três áreas que permitem um fluxo de trabalho entre as alterações e o
commit no nosso repositório.
• Working Directory - Onde são feitas as alterações ao código.
• Staging Area (Index) - Directoria onde sinalizamos que queremos guardar as
alterações.
• Repositório - Onde são realmente guardadas as alterações.
Podemos ver estas áreas como uma linha de montagem numa fabrica.
WD - Onde é efectuado realmente o trabalho.
SA - Onde é empacotado o produto.
REP - Onde é expedito o produto.
11. Conceitos git
Num projecto é normal existirem ficheiros que não queremos que o repositório controle.
Normalmente esses ficheiros são binários gerados pelo compilador, meta informação do IDE, etc…
Existe um ficheiro que deve ser logo adicionado ao repositório que indica que exclusões queremos
aplicar. Esse ficheiro deve ter o nome de “.gitignore”.
O conteúdo desse ficheiro indica ao repositório o que deve excluir. A sua sintaxe é bastante simples :
# Compiled source # <—Comentário
###################
*.class <— todos os ficheiros com a extensão .class não entram no repositório.
*.dll
*.exe
# Logs and databases #
######################
*.log
*.sql
*.sqlite
# OS generated files #
######################
.DS_Store
Thumbs.db
.gitignore
12. git init
Iniciar um novo repositório
Initialized empty Git repository in /PATH
Só depois de um repositório criado que começamos a
trabalhar com o git.
Obs :
13. git --bare init
Iniciar um novo repositório Bare
Initialized empty Git repository in /PATH
• Um repositório Bare não tem Working Directory.
• Serve para partilhar o repositório sem o perigo de
haver alterações acidentais.
Obs :
15. git status
Mostrar estado do repositório
ship:git101$ git status
On branch master <—————A branch onde estamos actualmente.
Initial commit
Changes to be committed: ↧ Estado actual da nossa branch ↧
(use "git rm --cached <file>..." to unstage)
new file: fix.txt
new file: resources/labels.properties
new file: src/Division.groovy
new file: src/Main.groovy
• Comando que irão executar mais vezes num
repositório git.
• Essencial para saber o que estamos a fazer…
• Neste caso temos ficheiros novos que temos que
adicionar ao repositório.
Obs :
16. git add filename or .
Adicionar ficheiros ao repositório
• Um repositório só tem utilidade se houver ficheiros
no repositório.
• Podemos usar o cmd “git add .” para adicionar
todos os ficheiros de uma só vez.
Obs :
Não tem output
17. git commit -m ‘Mensagem do commit’
Fazer um commit
ship:git101$ git add code1.txt <—- Adicionar as alterações a Stage Area
ship:git101$ git commit -m 'adicionei linha de codigo.’ <—— Fazer o commit
[master 24861d1] adicionei linha de codigo. <—— Output com a hash do commit e a msg
1 file changed, 1 insertion(+)
• É sempre antecedido pelo git add - Adicionamos
as alterações a Staging Area e depois fazemos o
commit das alterações
• É normalmente utilizado com o cmd “git status”
antes e depois do commit.
• Podemos fazer add e commit ao mesmo tempo
com o cmd git commit -am ‘Mensagem…’
Obs :
18. • Devem descrever sucintamente o que foi feito.
• Um commit deve ser visto como uma alteração, ou seja, não devemos fazer um
commit que introduza dez funcionalidades novas ou um que corrija um conjunto
de bugs.
Mau exemplo de mensagem (commit) :
Adicionei reset de password e Novo Menu na front page e Nova página de clientes e…
Bom exemplo :
commit 1 - Adicionei reset de password.
commit 2 - Adicionei novo menu.
commit 3 - Adicionei página Clientes.
p.s - É aqui que a Staging Area brilha, permite controlar o fluxo de commits que
queremos fazer.
Conceitos git
Mensagens de commit
19. git log
Ver histórico
• Trabalhar com o histórico num projecto com muitas
branches e muitos commits é melhor ter um
programa com GUI. Uma imagem vale mil
palavras…
Obs :
ship:git101$ git log
commit 24861d14b66a960a68ca9c563cf13b18095e4e0b <—— hash completo do commit
Author: NunoMachado <ngsmo@iscte-iul.pt> <—— Autor do commit
Date: Sun Oct 1 22:40:06 2015 +0100 <—— Data do commit
adicionei linha de codigo. <—— Mensagem do commit
commit a24d8ba4837c9cbd631c8750dcfa752b7e1f90bc
Author: NunoMachado <ngsmo@iscte-iul.pt>
Date: Sun Oct 1 22:25:41 2015 +0100
first commit
20. O comando log pode ser conjugado com um grande número parâmetros. Afinal
um dos objectivos de git é criar um histórico de desenvolvimento. É tão
importante o log que o git vem com uma interface gráfica para vermos o
histórico.
Exemplos :
• git log --oneline : Mostra cada commit só numa linha [hash]
Mensagem
• git log --graph : Mostra o histórico indicando a linha das branches
• git log --pretty=format:"%aD %h %an %s” : Permite formatar o
output. Existem diversas formatações possíveis.
• %aD - Data
• %h - Hash parcial. %H - Hash Total
• %an - Nome do Autor
• %s - Mensagem
Conceitos git
Comando log
23. git branch <NomeBranch>
Criar uma nova branch
• Criar branches no git é “barato”
• Ter em atenção que a nova branch é uma copia da
branch actual.
Obs :
24. git branch -d <NomeBranch>
Eliminar uma branch
• Se a branch que pretendemos eliminar não estiver
sido integrada em outra branch, então temos que
usar a flag -D
Obs :
ship:git101$ git branch -d newBranch
Deleted branch newBranch (was 24861d1).
25. git checkout <NomeBranch>
Navegar entre branches
• O git pode bloquear a troca de branches quando
existe alterações que se podem perder.
Obs :
ship:git101$ git checkout newBranch
Switched to branch 'newBranch'
26. git checkout -b <NomeBranch>
Criar uma branch e fazer o checkout
• É a forma mais comum de se criar uma branch.
Obs :
ship:git101$ git checkout -b feature
Switched to a new branch 'feature'
27. git pull . master
Buscar as diferenças para a branch actual
+ Merge
• O . indica que é o repositorio local
• master é a branch que tem as alterações que
queremos para a branch feature (actual)
• O comando pull vai buscar as alterações e faz o
merge automaticamente.
Obs :
ship:git101$ git checkout feature
Switched to branch 'feature'<—— Branch que vai receber as alterações
ship:git101$ git pull . master
From .
* branch master -> FETCH_HEAD
Updating 5bc101d..6c063a0
Fast-forward
b.txt | 2 ++
1 file changed, 2 insertions(+)
28. git fetch . master
Buscar as diferenças para a branch actual
• Só vai buscar as alterações entre as branches, não
aplica automaticamente.
• Ficheiro FETCH_HEAD tem as diferenças entre as
branches.
• O comando pull faz o fetch + merge por defeito.
Obs :
ship:git101$ git checkout feature
Switched to branch 'feature'<—— Branch que vai receber as alterações
ship:git101$ git pull . master
From .
* branch master -> FETCH_HEAD <—— Ficheiro onde tem as diferenças
Updating 5bc101d..6c063a0
Fast-forward
b.txt | 2 ++
1 file changed, 2 insertions(+)
29. git diff <file or branch> <file or branch>
Diferenças entre ficheiros ou branches
• O comando diff pode ser conjugado com diversos
parâmetros
Obs :
ship:git101$ git diff newFeature <—— Compara a branch actual (master) com a newFeature
diff --git a/code1.txt b/code1.txt
index 980a0d5..d8e6222 100644
--- a/code1.txt
+++ b/code1.txt
@@ -1 +1 @@
-Hello World! <—— Linha que saiu
+Ola Mundo <—— Linha que entrou
30. Conceitos git
Comando diff
• Podemos configurar o git para utilizar um differ diferente.
• Mais um caso em que um GUI para os diffs pode ser mais
intuitivo.
• O vosso IDE deve permitir ver os diffs rapidamente.
• O cmd git diff sem mais parametros faz a diferença entre a
Working Directory e o Index (Stage Area)
• Outro comando interessante é git diff HEAD que faz a
diferença entre a WD e o commit mais recente.
31. git merge <branch>
Junta as diferenças
ship:git101$ git merge newFeature <—— Faz o merge entre a branch master com a newFeature
Updating 1a6e26f..34cb942
Fast-forward <—— Estratégia que o git utilizou para o merge
code1.txt | 2 +-
code3.txt | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
32. Conceitos git
Comando Merge
• Fast-forward - Foi a estratégia que o git utilizou para fazer o
merge. Neste caso como os commits não era divergentes para
o git fazer o merge foi simplesmente apontar a branch master
para o último commit da branch newFeature. (Upstream)
• Se houvesse desenvolvimento ao mesmo tempo entre as duas
branches então o git iria optar por uma estratégia recursiva.
Basicamente o git vai procurar o ponto comum entre as duas
branches e começa a fazer o merge a partir desse ponto.
33. git tips
• Não compliquem desnecessariamente o workflow
desenvolvimento, quanto mais simples mais simples será a
gestão do código e facilita a detecção de erros.
• Manter a branch master num estado de release. Assim por
exemplo, conseguimos fazer uma branch para um “hotfix” sem
atrapalhar com o que estávamos a fazer actualmente, ou fazer
um revert para um estado estável.
• Mensagens de commit que façam sentido.
• Fazer backups em git é tão simples como fazer um copy-paste
da pasta de projecto. Façam isso antes de correr comandos
mais exóticos, ou se tiverem duvidas sobre o resultado =)
• StackOverflow continua a ser o melhor sítio para
programadores.