git init
git clone /caminho/para/o/repositório
git clone usuário@servidor:/caminho/para/o/repositório
seus repositórios locais consistem em três "árvores" mantidas pelo git. a primeira delas é sua Working Directory que contém os arquivos vigentes. a segunda Index que funciona como uma área temporária e finalmente a HEAD que aponta para o último commit (confirmação) que você fez.
git add <arquivo>
git add *
Este é o primeiro passo no fluxo de trabalho básico do git. Para realmente confirmar estas mudanças (isto é, fazer um commit), use
git commit -m "comentários das alterações"
Suas alterações agora estão no HEAD da sua cópia de trabalho local. Para enviar estas alterações ao seu repositório remoto, execute
git push origin master
Se você não clonou um repositório existente e quer conectar seu repositório a um servidor remoto, você deve adicioná-lo com
git remote add origin <servidor>
Branches ("ramos") são utilizados para desenvolver funcionalidades isoladas umas das outras. O branch master é o branch "padrão" quando você cria um repositório. Use outros branches para desenvolver e mescle-os (merge) ao branch master após a conclusão.
git checkout -b funcionalidade_x
git checkout master
git branch -d funcionalidade_x
git push origin <funcionalidade_x>
git pull
git merge <branch>
em ambos os casos o git tenta fazer o merge das alterações automaticamente. Infelizmente, isto nem sempre é possível e resulta em conflitos. Você é responsável por fazer o merge estes conflitos manualmente editando os arquivos exibidos pelo git. Depois de alterar, você precisa marcá-los como merged com
git add <arquivo>
git diff <branch origem> <branch destino>
é recomendado criar rótulos para releases de software. Este é um conhecido conceito, que também existe no SVN. Você pode criar um novo rótulo chamado 1.0.0 executando o comando
git tag 1.0.0 1b2e1d63ff
o 1b2e1d63ff representa os 10 primeiros caracteres do id de commit que você quer referenciar com seu rótulo. Você pode obter o id de commit com
git log
No caso de você ter feito algo errado (que seguramente nunca acontece ;) ) você pode sobrescrever as alterações locais usando o commando
git checkout -- <arquivo>
isto substitui as alterações na sua árvore de trabalho com o conteúdo mais recente no HEAD. Alterações já adicionadas ao index, bem como novos arquivos serão mantidos.
Se ao invés disso você deseja remover todas as alterações e commits locais, recupere o histórico mais recente do servidor e aponte para seu branch master local desta forma
git fetch origin
git reset --hard origin/master
gitk
git config color.ui true
git config format.pretty oneline
git add -i
- 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
echo "# teste" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/CristianoFIlho/teste.git
git push -u origin main
git remote add origin https://github.com/CristianoFIlho/teste.git
git branch -M main
git push -u origin main
Sinta-se a vontade para realizar adicionar mais informações ou realizar correções. Fork me!
Outros repositórios de ajuda:
Recursos Gratuitos