Git101pdf

101Nuno Machado [email]ngsmo@iscte-iul.pt [twitter] @logicb0x

Me, Myself and I• Nuno Machado

• ngsmo@iscte-iul.pt

• @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://nuno@iscte.pt/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 <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

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/