SlideShare uma empresa Scribd logo
1 de 36
Baixar para ler offline
101
Nuno 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 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.
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 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.
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 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.
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
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 git
Mensagens 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 git
Comando log
Conceitos git
gitk - 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 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.
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 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.
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/

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Git e Github
Git e GithubGit e Github
Git e Github
 
Git em pequenos projetos - Sandro Custódio - Tchelinux Livramento 2019
Git em pequenos projetos - Sandro Custódio - Tchelinux Livramento 2019Git em pequenos projetos - Sandro Custódio - Tchelinux Livramento 2019
Git em pequenos projetos - Sandro Custódio - Tchelinux Livramento 2019
 
Git - Fluxo do Versionamento adotado
Git - Fluxo do Versionamento adotadoGit - Fluxo do Versionamento adotado
Git - Fluxo do Versionamento adotado
 
Git e GitHub - Conceitos Básicos
Git e GitHub - Conceitos BásicosGit e GitHub - Conceitos Básicos
Git e GitHub - Conceitos Básicos
 
Controle de Versão Distribuído com Git básico
Controle de Versão Distribuído com Git básicoControle de Versão Distribuído com Git básico
Controle de Versão Distribuído com Git básico
 
Git - GitHub
Git - GitHubGit - GitHub
Git - GitHub
 
Controle de versão com e git
Controle de versão com e gitControle de versão com e git
Controle de versão com e git
 
Git workshop
Git workshopGit workshop
Git workshop
 
Controle de versão e colaboração com Git
Controle de versão e colaboração com GitControle de versão e colaboração com Git
Controle de versão e colaboração com Git
 
Controle de versionamento com Git
Controle de versionamento com GitControle de versionamento com Git
Controle de versionamento com Git
 
Git v2
Git v2Git v2
Git v2
 
Git
GitGit
Git
 
Git
GitGit
Git
 
Controle de Versões com Git
Controle de Versões com GitControle de Versões com Git
Controle de Versões com Git
 
Git+github
Git+githubGit+github
Git+github
 
Aprendendo Git
Aprendendo GitAprendendo Git
Aprendendo Git
 
Git e GitHub: Versionamento de Código Fácil
Git e GitHub: Versionamento de Código FácilGit e GitHub: Versionamento de Código Fácil
Git e GitHub: Versionamento de Código Fácil
 
Git para quem vem do SVN
Git para quem vem do SVNGit para quem vem do SVN
Git para quem vem do SVN
 
Git e Github para Iniciantes by Alysson Ajackson
Git e Github para Iniciantes by Alysson AjacksonGit e Github para Iniciantes by Alysson Ajackson
Git e Github para Iniciantes by Alysson Ajackson
 
Gerenciando projetos com Git e GitHub
Gerenciando projetos com Git e GitHubGerenciando projetos com Git e GitHub
Gerenciando projetos com Git e GitHub
 

Destaque

Começando com Git
Começando com GitComeçando com Git
Começando com GitDaniel Costa
 
09 - Fábio Akita - Além do rails
09 - Fábio Akita - Além do rails09 - Fábio Akita - Além do rails
09 - Fábio Akita - Além do railsDNAD
 
LT 08 - Guilherme Silveira - Cache hipermidia
LT 08 - Guilherme Silveira - Cache hipermidiaLT 08 - Guilherme Silveira - Cache hipermidia
LT 08 - Guilherme Silveira - Cache hipermidiaDNAD
 
LT 03 - Juan Lopes - Complexidade algoritmos
LT 03 - Juan Lopes - Complexidade algoritmosLT 03 - Juan Lopes - Complexidade algoritmos
LT 03 - Juan Lopes - Complexidade algoritmosDNAD
 
LT 05 - Ismael Apolinário - Importancia participacao cliente
LT 05 - Ismael Apolinário - Importancia participacao clienteLT 05 - Ismael Apolinário - Importancia participacao cliente
LT 05 - Ismael Apolinário - Importancia participacao clienteDNAD
 
LT 09 - Victor Cavalcante - Arquitetura não é só server side
LT 09 - Victor Cavalcante - Arquitetura não é só server sideLT 09 - Victor Cavalcante - Arquitetura não é só server side
LT 09 - Victor Cavalcante - Arquitetura não é só server sideDNAD
 
0210 bloqueando a opção salvar como
0210 bloqueando a opção salvar como0210 bloqueando a opção salvar como
0210 bloqueando a opção salvar comoAdilson Soledade
 

Destaque (7)

Começando com Git
Começando com GitComeçando com Git
Começando com Git
 
09 - Fábio Akita - Além do rails
09 - Fábio Akita - Além do rails09 - Fábio Akita - Além do rails
09 - Fábio Akita - Além do rails
 
LT 08 - Guilherme Silveira - Cache hipermidia
LT 08 - Guilherme Silveira - Cache hipermidiaLT 08 - Guilherme Silveira - Cache hipermidia
LT 08 - Guilherme Silveira - Cache hipermidia
 
LT 03 - Juan Lopes - Complexidade algoritmos
LT 03 - Juan Lopes - Complexidade algoritmosLT 03 - Juan Lopes - Complexidade algoritmos
LT 03 - Juan Lopes - Complexidade algoritmos
 
LT 05 - Ismael Apolinário - Importancia participacao cliente
LT 05 - Ismael Apolinário - Importancia participacao clienteLT 05 - Ismael Apolinário - Importancia participacao cliente
LT 05 - Ismael Apolinário - Importancia participacao cliente
 
LT 09 - Victor Cavalcante - Arquitetura não é só server side
LT 09 - Victor Cavalcante - Arquitetura não é só server sideLT 09 - Victor Cavalcante - Arquitetura não é só server side
LT 09 - Victor Cavalcante - Arquitetura não é só server side
 
0210 bloqueando a opção salvar como
0210 bloqueando a opção salvar como0210 bloqueando a opção salvar como
0210 bloqueando a opção salvar como
 

Semelhante a Git 101

Minicurso GIT 2022 - SENAC
Minicurso GIT 2022 - SENACMinicurso GIT 2022 - SENAC
Minicurso GIT 2022 - SENACDanilo Pinotti
 
Minicurso GIT Completo (2022)
Minicurso GIT Completo (2022)Minicurso GIT Completo (2022)
Minicurso GIT Completo (2022)Danilo Pinotti
 
Introdução ao Git
Introdução ao GitIntrodução ao Git
Introdução ao GitOto Junior
 
Introdução ao git
Introdução ao gitIntrodução ao git
Introdução ao gitDiogo Gomes
 
Descomplicando o controle de versão com git
Descomplicando o controle de versão com gitDescomplicando o controle de versão com git
Descomplicando o controle de versão com gitHumberto Streb
 
Desmistificando a ferramenta git
Desmistificando a ferramenta gitDesmistificando a ferramenta git
Desmistificando a ferramenta gitDiogo Souza Machado
 
Minicurso GIT PET Computação
Minicurso GIT PET ComputaçãoMinicurso GIT PET Computação
Minicurso GIT PET ComputaçãoBruno Orlandi
 
GIT - Gerenciamento de Projeto e Versionamento Semântico
GIT - Gerenciamento de Projeto e Versionamento SemânticoGIT - Gerenciamento de Projeto e Versionamento Semântico
GIT - Gerenciamento de Projeto e Versionamento SemânticoDjanilson Alves
 
Git - Sistema Descentralizado de Controle de Versões
Git - Sistema Descentralizado de Controle de VersõesGit - Sistema Descentralizado de Controle de Versões
Git - Sistema Descentralizado de Controle de VersõesLeandro Cavalcante
 
Intervalo técnico Git/SVN
Intervalo técnico Git/SVNIntervalo técnico Git/SVN
Intervalo técnico Git/SVNLuciano Lima
 
EIIFRO2014 - Desenvolvimento Colaborativo de Software
EIIFRO2014 - Desenvolvimento Colaborativo de SoftwareEIIFRO2014 - Desenvolvimento Colaborativo de Software
EIIFRO2014 - Desenvolvimento Colaborativo de SoftwareAldson Diego
 
Git controlo de_versoes
Git controlo de_versoesGit controlo de_versoes
Git controlo de_versoesRicardo Soares
 

Semelhante a Git 101 (20)

Minicurso GIT 2022 - SENAC
Minicurso GIT 2022 - SENACMinicurso GIT 2022 - SENAC
Minicurso GIT 2022 - SENAC
 
Git
GitGit
Git
 
Minicurso GIT Completo (2022)
Minicurso GIT Completo (2022)Minicurso GIT Completo (2022)
Minicurso GIT Completo (2022)
 
Introdução ao Git
Introdução ao GitIntrodução ao Git
Introdução ao Git
 
Introdução ao git
Introdução ao gitIntrodução ao git
Introdução ao git
 
Ferramenta git
Ferramenta gitFerramenta git
Ferramenta git
 
Descomplicando o controle de versão com git
Descomplicando o controle de versão com gitDescomplicando o controle de versão com git
Descomplicando o controle de versão com git
 
Desmistificando a ferramenta git
Desmistificando a ferramenta gitDesmistificando a ferramenta git
Desmistificando a ferramenta git
 
Minicurso GIT PET Computação
Minicurso GIT PET ComputaçãoMinicurso GIT PET Computação
Minicurso GIT PET Computação
 
Git
GitGit
Git
 
Oficina de Git EEDACT2015
Oficina de Git EEDACT2015Oficina de Git EEDACT2015
Oficina de Git EEDACT2015
 
GIT - Hands-On
GIT - Hands-On GIT - Hands-On
GIT - Hands-On
 
GIT - Gerenciamento de Projeto e Versionamento Semântico
GIT - Gerenciamento de Projeto e Versionamento SemânticoGIT - Gerenciamento de Projeto e Versionamento Semântico
GIT - Gerenciamento de Projeto e Versionamento Semântico
 
Git - Sistema Descentralizado de Controle de Versões
Git - Sistema Descentralizado de Controle de VersõesGit - Sistema Descentralizado de Controle de Versões
Git - Sistema Descentralizado de Controle de Versões
 
Intervalo técnico Git/SVN
Intervalo técnico Git/SVNIntervalo técnico Git/SVN
Intervalo técnico Git/SVN
 
Git + git hub
Git + git hubGit + git hub
Git + git hub
 
Git e github
Git e githubGit e github
Git e github
 
EIIFRO2014 - Desenvolvimento Colaborativo de Software
EIIFRO2014 - Desenvolvimento Colaborativo de SoftwareEIIFRO2014 - Desenvolvimento Colaborativo de Software
EIIFRO2014 - Desenvolvimento Colaborativo de Software
 
Git ao GitHub
Git ao GitHubGit ao GitHub
Git ao GitHub
 
Git controlo de_versoes
Git controlo de_versoesGit controlo de_versoes
Git controlo de_versoes
 

Git 101

  • 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 :
  • 14. 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 :
  • 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
  • 21. Conceitos git gitk - Interface gráfica que vem com o git
  • 22. git branch Listar Branches ship:git101$ git branch * master <—— * Branch que estamos a trabalhar. newBranch
  • 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.
  • 35. Agradecimentos • A vossa presença! • Ao Nuno Cancelo pela sua disponibilidade e revisão da apresentação.
  • 36. 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/