Embed Size (px)
Citation preview
Me, Myself and I• Nuno Machado
• @logicB0x
• Programador : C# / .NET
• Estudante : MEI
• Membro do ACM
Objectivos
• Aprender os conceitos básicos de git
• Conseguir gerir um repositório
• Guardar uma “cabula” de comandos
Source Version ControlCentral 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.
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.
Instalar git
https://git-scm.com/download/linux
https://git-scm.com/download/mac
https://git-scm.com/download/win
Configurar gitExistem 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.
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 :
Conceitos git
Conceitos gitEm 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.
Conceitos gitNum 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
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 :
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 :
git clone <ssh://[email protected]/reps/robots.git>
Copiar um repositório remoto
Cloning into 'robots'...
• Sabemos que é um repositório Bare porque segue a convenção da extensão .git.
Obs :
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 :
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
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 :
• 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 gitMensagens de commit
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 <[email protected]> <—— 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 <[email protected]> Date: Sun Oct 1 22:25:41 2015 +0100
first commit
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 gitComando log
Conceitos gitgitk - Interface gráfica que vem com o git
git branch
Listar Branches
ship:git101$ git branch * master <—— * Branch que estamos a trabalhar. newBranch
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 :
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).
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'
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'
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(+)
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(+)
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
Conceitos gitComando 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.
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(-)
Conceitos gitComando 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.
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.
git tools
Agradecimentos• A vossa presença! • Ao Nuno Cancelo pela sua disponibilidade e revisão da
apresentação.
Referências Git - https://git-scm.com/ Git Book (free) - https://git-scm.com/book/en/v2 Beginner Tutorial - https://www.atlassian.com/git/tutorials/ Github - https://github.com/ Bitbucket - https://bitbucket.org/
Free Stuff =)
https://education.github.com/pack
https://blog.bitbucket.org/2011/04/01/free-unlimited-user-source-code-hosting-for-university-students/
