Comando Git
- Iniciar o diretório:
git bash - Mostrar o status dos arquivos:
git status - Adicionar todos os arquivos para envio:
git add . - Inserindo comentários:
git commit -m "Inserir comentário" - Clonar um repositório (o nome é opcional):
git clone "link_do_repositorio" "nome_do_repositorio" - Enviando o projeto para o Github:
git push -u origin "nome_do_branch"
- Permite revisar o texto do último commit local:
git commit --amend
- Mostra o nome do usuário que alterou um arquivo:
git blame "nome_do_arquivo" - (-w) Ignora os espaços em branco (-e) Ao invés de mostrar o nome, mostra o e-mail:
git blame -w -e "nome_do_arquivo"
- Lista os branches e mostra o branch que está sendo utilizado:
git branch - Deleta um branch:
git branch -D "nome_do_branch"
- Recupera os arquivos do repositório até o último commit realizado:
git checkout -- . - Seleciona o branch:
git checkout "nome_do_branch" - Retorna as mudanças realizadas:
git checkout "nome_do_arquivo" - Cria um branch (ramificação):
git checkout -b "nome_do_branch"
- Configurando o nome no Git:
git config --global user.name "Seu nome" - Configurando o e-mail no Git:
git config --global user.email "Seu e-mail" - Configurando o editor:
git config --global core.editor "nome_do_editor" - Mostrar o username:
git config user.name - Mostrar toda a configuração do Git:
git config --list
- Mostra a modificação realizada:
git diff - Mostra os arquivos modificados:
git diff --name-only
- Mostra quem fez as alterações:
git log ou git log --decorate - Mostra todos os arquivos editados por uma pessoa:
git log --author="nome_do_autor" - Mostra em forma gráfica:
git log --graph - Mostra os commits de forma resumida:
git log --oneline
- Une um branch a branch atual:
git merge "nome_do_branch"
- Altera o endereço do repositório remoto:
git remote set-url origin http://meu-novo-endereco/meu-projeto.git - Verifica o endereço do seu repositório atual:
git remote -v - Remove o repositório atual:
git remote rm origin
- Retorna status do arquivo inserido no "git add":
git reset HEAD "nome_do_arquivo" - Retorna o status de um commit:
git reset "(--soft, --mixed ou --hard)" "codigo_hash"
- Mostra o nome e arquivos editados, em ordem alfabética:
git shortlog - Mostra o nome do(s) autor(es) em ordem alfabética:
git shortlog -sn
- Mostra as edições realizadas:
git show "codigo_hash"
- Salva as alterações de um arquivo:
git stash - Retornas as alterações de um arquivo:
git stash apply - Lista os arquivos salvos pelo stash:
git stash list - Limpa a lista de arquivos salvos:
git stash clear
Não é possível desfazer um push diretamente, como é feito com o commit utilizando o comando $ git reset --soft|mixed|hard hash-do-penultimo-commit
Para desfazer um push são necessários 3 passos:
- Utilizar o comando
$ git reset --mixed hash-do-penultimo-commite em seguida utilizar o comando$ git stash - Utilizar o comando
$ git revert hash-do-ultimo-commit - Utilizar o comando
$ git stash apply
No passo 1, estamos recuperando os arquivos enviados com o git reset e criando um 'ponto de restauração' com o git stash para não perdermos as modificações enviadas.
No passo 2, criamos um novo commit revertendo o commit anterior, apagando as modificações realizadas.
No passo 3, utilizamos o 'ponto de restauração' criado no passo 1 para recuperar as modificações realizadas antes do push.
Para verificar os logs do commit podemos utilizar o comando $ git log --stat que mostra o hash, a descrição e os arquivos modificados nos commits.
Pronto!
Cada mensagem de commit consiste em um cabeçalho, um corpo e um rodapé.
Tem um formato pré-definido, que inclui um tipo e um título:
<tipo>(<escopo opcional>): <título>
<corpo opcional>
<rodapé opcional>
Exemplos:
fix(integracao-erp): xxxxxxx
improve(app-toolbox): xxxxxxx
docs: instruções de iniciar projeto com docker
O cabeçalho é obrigatório.
Qualquer linha da mensagem do commit não pode ter mais de 100 caracteres! Assim fica mais fácil para ler no GitHub, Gitlab e outras ferramentas de git.
Deve ser um dos seguintes:
- build: alterações que afetam o sistema de build ou dependências externas
- static: alterações no conteúdo de arquivos estáticos (dados .json, imagens, etc)
- ci: alterações em nossos arquivos e scripts de configuração de CI
- cd: alterações em nossos arquivos e scripts de configuração para CD
- docs: somente alterações na documentação
- feat: um novo recurso
- fix: uma correção de bug da aplicação
- perf: alteração de código que melhora o desempenho da aplicação e não altera a forma como o usuário utiliza a aplicação
- refactor: alteração de código, que não corrige um bug e nem altera a forma como o usuário utiliza a aplicação
- improve: alguma alteração de código que melhore o comportamento de um recurso
- style: alterações que não afetam o significado do código (espaço em branco, formatação, ponto e vírgula, etc)
- test: adicionando testes ausentes ou corrigindo testes existentes
- revert: reverter para um commit anterior
O título contém uma descrição sucinta da mudança:
- use o imperativo, tempo presente: "mudança" não "mudou" nem "muda"
- não capitalize a primeira letra
- sem ponto (.) no final
Um corpo de mensagem de commit mais longo PODE ser fornecido após o título, fornecendo informações contextuais adicionais sobre as alterações no código.
Configure a mensagem com um wrap de 80 caracteres
Use para explicar "o que" e "porque" foi realizado essa modificação, ao invez de "como".
O corpo DEVE começar depois de uma linha em branco após a descrição.
Um rodapé PODE ser fornecido depois de uma linha em branco após o corpo.
Caso exista um ticket no jira, criar um referência assim: issue TP-666 ou closes issue TP-666
Se o commit reverte um commit anterior, ele deve começar por revert:, seguido pelo cabeçalho do commit revertido.
No corpo, ele deve dizer: Isso reverte o commit <hash> ., onde o hash é o SHA do commit sendo revertido.
- Criação automatizada de CHANGELOGs
- Determinar automaticamente um aumento de versionamento semântico (com base nos tipos de commits)
- Comunicar a natureza das mudanças para colegas de equipe, o público e outras partes interessadas de forma padronizada
- Disparar processos de build e deploy
- Facilitar a contribuição de outras pessoas em seus projetos, permitindo que eles explorem um histórico de commits mais estruturado e com melhor rastreabilidade
Referência: Conventional Commits
- Modificado (modified);
- Preparado (staged/index)
- Consolidado (comitted);
git help
git help add
git help commit
git help <qualquer_comando_git>
As configurações do GIT são armazenadas no arquivo .gitconfig localizado dentro do diretório do usuário do Sistema Operacional (Ex.: Windows: C:\Users\Documents and Settings\Leonardo ou *nix /home/leonardo).
As configurações realizadas através dos comandos abaixo serão incluídas no arquivo citado acima.
git config --global user.name "Leonardo Comelli"
git config --global user.email leonardo@software-ltda.com.br
git config --global core.editor vim
git config --global merge.tool vimdiff
git config --global core.excludesfile ~/.gitignore
git config --list
Os nomes de arquivos/diretórios ou extensões de arquivos listados no arquivo .gitignore não serão adicionados em um repositório. Existem dois arquivos .gitignore, são eles:
-
Geral: Normalmente armazenado no diretório do usuário do Sistema Operacional. O arquivo que possui a lista dos arquivos/diretórios a serem ignorados por todos os repositórios deverá ser declarado conforme citado acima. O arquivo não precisa ter o nome de .gitignore.
-
Por repositório: Deve ser armazenado no diretório do repositório e deve conter a lista dos arquivos/diretórios que devem ser ignorados apenas para o repositório específico.
git init
git status
git add meu_arquivo.txt
git add meu_diretorio
git add .
git add -f arquivo_no_gitignore.txt
git commit meu_arquivo.txt
git commit meu_arquivo.txt meu_outro_arquivo.txt
git commit meuarquivo.txt -m "minha mensagem de commit"
git rm meu_arquivo.txt
git rm -r diretorio
git log
git log -p -2
git log --stat
git log --pretty=oneline
git log --pretty=format:"%h - %an, %ar : %s"
- %h: Abreviação do hash;
- %an: Nome do autor;
- %ar: Data;
- %s: Comentário.
Verifique as demais opções de formatação no Git Book
git log -- <caminho_do_arquivo>
git log --summary -S<palavra> [<caminho_do_arquivo>]
git log --diff-filter=M -- <caminho_do_arquivo>
- O pode ser substituido por: Adicionado (A), Copiado (C), Apagado (D), Modificado (M), Renomeado (R), entre outros.
git log --author=usuario
git blame -L 12,22 meu_arquivo.txt
Este comando deve ser utilizando enquanto o arquivo não foi adicionado na staged area.
git checkout -- meu_arquivo.txt
Este comando deve ser utilizando quando o arquivo já foi adicionado na staged area.
git reset HEAD meu_arquivo.txt
Se o resultado abaixo for exibido, o comando reset não alterou o diretório de trabalho.
Unstaged changes after reset:
M meu_arquivo.txt
A alteração do diretório pode ser realizada através do comando abaixo:
git checkout meu_arquivo.txt
git remote
git remote -v
git remote add origin git@github.com:leocomelli/curso-git.git
git remote show origin
git remote rename origin curso-git
git remote rm curso-git
O primeiro push de um repositório deve conter o nome do repositório remoto e o branch.
git push -u origin master
Os demais pushes não precisam dessa informação
git push
git pull
git fetch
git clone git@github.com:leocomelli/curso-git.git
git tag vs-1.1
git tag -a vs-1.1 -m "Minha versão 1.1"
Para criar uma tag assinada é necessário uma chave privada (GNU Privacy Guard - GPG).
git tag -s vs-1.1 -m "Minha tag assinada 1.1"
git tag -a vs-1.2 9fceb02
git push origin vs-1.2
git push origin --tags
O master é o branch principal do GIT.
O HEAD é um ponteiro especial que indica qual é o branch atual. Por padrão, o HEAD aponta para o branch principal, o master.
git branch bug-123
git checkout bug-123
Neste caso, o ponteiro principal HEAD esta apontando para o branch chamado bug-123.
git checkout -b bug-456
git checkout master
git merge bug-123
Para realizar o merge, é necessário estar no branch que deverá receber as alterações. O merge pode automático ou manual. O merge automático será feito em arquivos textos que não sofreram alterações nas mesmas linhas, já o merge manual será feito em arquivos textos que sofreram alterações nas mesmas linhas.
A mensagem indicando um merge manual será:
Automerging meu_arquivo.txt
CONFLICT (content): Merge conflict in meu_arquivo.txt
Automatic merge failed; fix conflicts and then commit the result.
git branch -d bug-123
git branch
git branch -v
git branch --merged
git branch --no-merged
git push origin bug-123
git push origin bug-123:new-branch
git checkout -b bug-123 origin/bug-123
git push origin:bug-123
Fazendo o rebase entre um o branch bug-123 e o master.
git checkout experiment
git rebase master
Mais informações e explicações sobre o Rebasing
###Stash
Para alternar entre um branch e outro é necessário fazer o commit das alterações atuais para depois trocar para um outro branch. Se existir a necessidade de realizar a troca sem fazer o commit é possível criar um stash. O Stash como se fosse um branch temporário que contem apenas as alterações ainda não commitadas.
git stash
git stash list
git stash apply
git stash apply stash@{2}
Onde 2 é o indíce do stash desejado.
git stash branch meu_branch
git commit --amend -m "Minha nova mensagem"
Alterando os três últimos commits
git rebase -i HEAD~3
O editor de texto será aberto com as linhas representando os três últimos commits.
pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added catfile
Altere para edit os commits que deseja realizar alterações.
edit f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added catfile
Feche o editor de texto.
Digite o comando para alterar a mensagem do commit que foi marcado como edit.
git commit –amend -m “Nova mensagem”
Aplique a alteração
git rebase --continue
Atenção: É possível alterar a ordem dos commits ou remover um commit apenas mudando as linhas ou removendo.
Seguir os mesmos passos acima, porém marcar os commtis que devem ser juntados com *squash
git filter-branch --tree-filter 'rm -f passwords.txt' HEAD
O bisect (pesquisa binária) é útil para encontrar um commit que esta gerando um bug ou uma inconsistência entre uma sequência de commits.
git bisect start
git bisect bad
git bisect good vs-1.1
O GIT irá navegar entre os commits para ajudar a indentificar o commit que esta com o problema. Se o commit atual não estiver quebrado, então é necessário marca-lo como bom.
git bisect good
Se o commit estiver com o problema, então ele deverá ser marcado como ruim.
git bisect bad
Depois de encontrar o commit com problema, para retornar para o HEAD utilize:
git bisect reset
Esse exemplo mostra todos os arquivos alterados nos últimos dois dias, sem repetir:
git log --pretty=format: --name-only --since="2 days ago" | sort | uniqO uso de repositórios GIT tem diversos benefícios: trabalho em equipe, desenvolvimento de recursos separadamente, histórico das alterações, etc. Mas para disponibilizar todo o potencial é preciso um pouco de dedicação no momento do commit.
Não é preciso uma vasta experiência para já ter passado por situações como conflito de arquivos onde a mensagem não traz nenhuma informações relevante e é preciso inverstigar o que a outra pessoa estava desenvolvendo ou após atualizar o repositório ver uma mensagem de depuração no meio da aplicação.
Ao fazer commit recomendo reservar uns 5 minutos para dar atenção especial a:
- sincronização do repositório remoto
- revisar código
- conferir arquivos que serão incluídos (staged)
- mensagem de commit.
A simples execução do comando git pull evita merges desnecessários que
"sujam" o histórico do repositório e retrabalhos inesperados que podem surgir
ao fazer push.
Ao sincronizar com o repositório remoto antes de iniciar o commit possíveis conflitos de código são antecipados e podem ser resolvidos junto com a revisão do código, unificar essas duas tarefas faz parecer uma só.
Tão importante quanto pull é o push, que deve ser feito logo após o commit, principalmente se houver outras pessoas trabalhando no mesmo recurso, caso contrário o cuidado será em vão, pois as situações apresentadas antes podem acontecer.
Por favor, não negligencie essa etapa com git add . a pressa e falta de
cuidado podem causar pequenos problemas que atrapalham o trabalho.
É possivel fazer essa tarefa usando apenas o terminal executando o comando
git diff, mas usar a IDE vai facilitar muito pois a maioria delas oferece
comparação lado a lado da versão atual e anterior do arquivo. Nesse momento
você terá a oportunidade de ler o código escrito, refinar a lógica, ajustar
nomes de funções e variáveis e remover códigos de depuração e alterações feitas
apenas para teste.
Se após revisar houver certeza que todos os arquivos devem fazer parte do commit
use git add ., caso contrário a inclusão ou stage deve ser feita um arquivo
por vez, adicionando apenas dos arquivos que de fato fazem parte do recurso.
Novamente a IDE pode ajudar nessa etapa, que também pode ser feita por linha de
comando.
Recomendações para uma boa mensagem 1
T.L. D.R. (Longo demais, não li):
- Separar título e descrição com uma linha em branco
- Tente limitar o título a 50 caracteres, ou no máximo 72
- Iniciar título com letra maiúscula
- O título não deve terminar com ponto
- Use o modo indicativo do presente no título
- Na descrição faça quebras de linha em até 72 caracteres
- Use a descrição para explicar o que e o porquê e não como
Exemplo:
Resume alteração em 50 caracteres
Texto com explicação mais detalhada, caso necessário. Com quebra de
linha em 72 caracteres ou menos. A primeira linha é o título e o
restante do texto a descrição. A linha em branco separando os dois é
obrigatória (a menos que não tenha descrição); vários comandos como
`log`, `shotlog` e `rebase` se comportam de forma inesperada se os dois
elementos estiverem juntos.
Explicação do problema que o _commit_ resolve. Focando no motivo ao
invés como (isso o código explica). Existem efeitos colaterais ou
consequências não intuitívas? Aqui é o local para dizer.
- listas funcionam
- geralmente com um hífem ou asterisco, precedido de espaço, com
linhas entre os items
É possivel referenciar _issues_:
Resolve: #123Agora, vamos detalhar cada um dos itens destacados.
Nem todo commit precisa de título e descrição. Muitas vezes apenas uma linha é o suficiente, especialmente quando é feita uma mudança simples. Por exemplo:
Corrige erro de digitação no dashboard
Não há mais nada para dizer. Para saber qual foi o erro, basta ver a
alteração com git show, git diff ou git log -p.
Quando o commit merece um pouco de contextualização e/ou explicação, use a descrição. Por exemplo:
Exibe legenda "sem dados" no gráfico e remove consulta por mês
Os dados da consulta mensal são os mesmos da lista de procedimentos,
remove a consulta e consolida os dados pela lista no front-end.
Mensagens de commit com descrição são complicadas para escrever com o
parâmetro -m. Nesses casos é necessário ter configurado um editor como
vim ou nano, ou usar uma IDE com suporte de mensagem de commit multi-linha.
De qualquer forma a separação se torna evidente ao navegar pelo histórico. Essa é uma entrada de log completa:
commit 6f668d049f1fef12d775da57dd8fdd8ef81fa1dc
Author: Pedro Sanção <pedrosancao@users.noreply.github.com>
Date: Wed Jan 15 12:06:58 2020 -0200
Exibe legenda "sem dados" no gráfico e remove consulta por mês
Os dados da consulta mensal são os mesmos da lista de procedimentos,
remove a consulta e consolida os dados pela lista no front-end.
E essa é a mesma entrada com git log --oneline:
6f668d Exibe legenda "sem dados" no gráfico e remove consulta por mês
Manter o título com menos de 50 caracteres torna ele legível no histórico e te força a pensar na forma mais concisa de explicar o que está acontecendo.
Se for muito difícil resumir, é possível que o commit tenha uma alteração muito grande e pode ser necessário dividi-lo.
Simples como escrito. O título deve ser iniciado com letra maiúscula.
Use:
Adiciona contâiner do banco de dados Oracle ✔
Ao invés de:
adiciona contâiner do banco de dados Oracle ❌
Estamos tentando resumir o título em 50 caracteres, então por que gastar mais um com o ponto final?
O modo indicativo é um modo verbal que expressa uma certeza, um fato.
Se a mensagem de commit for em inglês o tempo verbal recomendado é o imperativo, que geralmente representa uma ordem ou comando.
Algumas vezes essa forma pode parecer rude e por isso é pouco usada. Mas é perfeita para os títulos. O próprio GIT usa essa forma ao fazer commits por você.
Por exemplo, a mensagem padrão de merge:
Merge 'my featur' into develop
Ou em tradução livre:
Mescla ramificação 'meu-recurso' para develop
Ou git revert:
Reverte "Cria recurso experimental"
Então ao escrever mensagens de commit use o modo indicativo no presente, por exemplo:
- Atualiza estilos da página inicial ✔
- Trata exceção de tempo expirado na sincronização ✔
- Corrige bug da interação de filtros ✔
- Adiciona cliente da API de pagamentos ✔
Escrever dessa forma pode ser estranho no começo. Estamos mais acostumados a usar o tempo passado ou gerúdio ao descrever as mudanças, por isso é comum encontrar títulos como:
- Corrigindo bug no envio de e-mail ❌
- Atualizei texto do blog ❌
E algumas vezes a mensagem é a descrição do conteúdo
- Endpoint da API para importação ❌
- Novo fluxo de compra ❌
Para evitar confusão há uma regra simples para acertar todas as vezes. O título deve completar a frase "Se aplicado, esse commit seu título". Por exemplo:
- Se aplicado, esse commit atualiza estilos da página inicial ✔
- Se aplicado, esse commit trata exceção de tempo expirado na sincronização ✔
- Se aplicado, esse commit corrige bug da interação de filtros ✔
- Se aplicado, esse commit adiciona cliente da API de pagamentos ✔
Veja como não faz sentido ao usar com outras formas:
- Se aplicado, esse commit corrigindo bug no envio de e-mail ❌
- Se aplicado, esse commit atualizei texto do blog ❌
- Se aplicado, esse commit endpoint da API para importação ❌
- Se aplicado, esse commit novo fluxo de compra ❌
Lembrando que esse modo se aplica apenas ao título. A descrição não está limitada a essa restrição.
O GIT nunca faz quebras de linha automaticamente. Ao escrever a descrição do commit você precisa medir a margem direita e quebrar linha manualmente.
A recomendação de 72 caracteres é para que o GIT tenha espaço para indentar, e manter tudo em menos de 80 caracteres.
Um editor pode ajudar aqui. É possível configurar plugins do Vim para fazer as quebras de linhas por você. Algumas IDEs suportam mensagens multi-linha e já tem uma linha após o 72º caracter.
Eis um exemplo de uma mensagem destacando o quê mudou e o porquê:
Grava estado dos dados simulados no teste de interface
Grava o estado dos dados aleatórios gerados para posterior manipulação
tornando o comportamento da inteface mais próximo do que acontece com
dados reais.
O estado foi armazenado no cache da aplicação para que todos os
usuários vejam os mesmos dados permitindo comparação entre navegadores
distintos.
Nesse exemplo a alteração foi contextualizada e as escolhas explicadas. O que pode salvar tempo para a próxima pessoa que alterar o código em questão. Caso as informações fornecidas não fossem registradas aqui elas seriam perdidas para sempre.
Na maioria dos casos, você pode deixar de lado como a alteração foi feita. Geralmente o código é auto-explicativo. Se for complexo demais comentários de código pontuais são permitidos. Deixe claro os motivos para a mudança, a forma de funcionamento antes da alteração e qual o problema existente, como funciona agora e porque você decidiu resolver dessa forma.
A próxima pessoa que vai te agradecer pode ser você mesmo.
- gitg
- plugin GitLens para VSCode
- plugin GitToolbox para PHP Storm
Sinta-se a vontade para realizar adicionar mais informações ou realizar correções. Fork me!