git init
git add .
git commit -m "first commit"
git remote add origin https://github.com/seu-usuario/Nome-do-Repo-Remoto.git
git push -u origin master
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 "Rodrigo Alves"
git config --global user.email [email protected]
git config --global core.editor vim
git config --global merge.tool vimdiff
git config --global core.excludesfile ~/.gitignore
git config --list
git config color.ui true
git config format.pretty oneline
=====================================================
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.
Existem alguns arquivos que muito provavelmente você não vai precisar versionar, como por exemplo os arquivos de cache do SASS, arquivos de configuração e etc. Nesse caso você precisa fazer com que o controle de versão ignore estes arquivos. Para tanto, crie um arquivo chamado .gitignore. Feito isso, dentro deste arquivo, digite o nome ou o endereço das pastas que você quer ignorar. Um exemplo:
See http://help.github.com/ignore-files/ for more about ignoring files.
If you find yourself ignoring temporary files generated by your text editor or operating system, you probably want to add a global ignore instead:
git config --global core.excludesfile ~/.gitignore_global
/.bundle
/build
/.sass-cache
.DS_Store .cache .rvmrc
vendor/*
*.swp *.swo
.ruby-version
deploy
Gemfile.lock .vagrant Vagrantfile
=====================================================
Entre no diretório que deseja controlar a versão e inicie o Git assim:
git init
Feito isso, seus arquivos ainda não estão sendo versionados, mas eles estão esperando para serem adicionados no estágio de controle. Para fazer isso digite o comando
git add nome-do-arquivo-incluindo-extensão
Saber o status do projeto é importante. Com o comando abaixo você consegue ver quais arquivos estão fora do controle, quais foram modificados e estão esperando por uma descrição de modificação etc:
git status
- Modificado (modified);
- Preparado (staged/index)
- Consolidado (comitted);
git add meu_arquivo.txt
git add meu_diretorio
Se você precisa adicionar todos os arquivos do diretório, basta digitar:
git add .
git add -f arquivo_no_gitignore.txt
git add -i
git reset HEAD nome-do-arquivo
=====================================================
git commit meu_arquivo.txt
git commit meu_arquivo.txt meu_outro_arquivo.txt
git commit meuarquivo.txt -m "minha mensagem de commit"
git commit -a -m "Mensagem do commit"
$ git commit --amend
git reset HEAD~1
git reset HEAD~2
git reset HEAD~1 --soft
git reset HEAD~1 --hard
Se o arquivo ainda não está commited:
git checkout -- [path]
Se já foi committed e quer voltar pro commit imediatamente anterior ao HEAD:
git reset HEAD~1 [path]
Ou
git checkout HEAD~1 [path]
=====================================================
git rm meu_arquivo.txt
git rm -r diretorio
git ls-files --deleted | xargs git rm
=====================================================
git log
git log -p
git log -p -2
Exibir resumo do histórico (hash completa, autor, data, comentário e qtde de alterações (+/-)). Mostrando as estatísticas de todos os commits:
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 --since=2.days
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
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.
Primeiro passo:
git rebase -i --root
Com este comando será aberto o VIM. Então siga estes passos:
- Delete o comentário ou a parte que deseja alterar do comentário usando a tecla delete
- clica emcima da palavra "pick" antes do comentário e aperte 'S'
- ao aparece embaixo "-- INSERÇÃO --", digite 'r'
- aperte CTRL + C, digite ':wq'
- Você será direcionado para outro arquivo, sendo esse específico do comentário, para alterar também. Siga apenas os passos anteriores e saia do VIM. Aguarde o termino do comando "rebase"
:wq
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
=====================================================
git checkout -b nome-do-branch
git branch
git checkout master
git merge nome-do-branch-que-foi-criado
git rebase nome-do-branch-que-foi-criado
git branch -D nome-do-branch
git branch -a
git fecth
=====================================================
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 [email protected]: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 push origin nome-do-branch
=====================================================
Trazendo, puxando as alterações feitas por outros usuários:
git pull origin master
Sincronizando tudo que está no repositório remoto:
git pull
git fecth
=====================================================
Use o comando git clone url-do-projeto. Exemplo:
git clone [email protected]:leocomelli/curso-git.git
git checkout -b nome-do-branch origin/ nome-do-branch
=====================================================
As tags servem para marcar uma etapa. Imagine que você vai lançar uma versão, que resolve uma série de problemas. Você pode marcar aquela etapa criando uma tag. Assim fica simples de fazer qualquer rollback do projeto para uma tag específica em vez de voltar para um commit. Você sabe que tudo o que foi feito até aquela tag está funcionando.
git tag vs-1.1
(git tag versão-da-tag)
git tag -l
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 master --tags
git tag -d versão-da-tag
git push origin :refs/tags/versão-da-tag
=====================================================
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
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 pop
git stash drop
git stash drop [ nome do stash ]
git stash branch meu_branch
======================================================
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
=====================================================
Ocasionalmente, Git automaticamente executa um comando chamado "auto gc". Na maioria das vezes, este comando não faz nada. No entanto, se houverem muitos objetos soltos (loose objects) (objetos que não estejam em um packfile) ou muitos packfiles, Git executa um verdadeiro comando git gc. O gc significa garbage collect (coleta de lixo), e o comando faz uma série de coisas: ele reúne todos os objetos soltos e os coloca em packfiles, consolida packfiles em um packfile maior, e remove objetos que não estejam ao alcance de qualquer commit e tem poucos meses de idade.
Você pode executar auto gc manualmente da seguinte forma:
git gc --auto
=====================================================
Se você quer continuar ou iniciar seus estudos com Git, o pessoal da CodeSchool juntamente com o GitHub fizeram uma página exclusivamente para ensinar Git na prática. Visite aqui: https://try.github.io/levels/1/challenges/1
Há também a documentação do Git que é bastante completa: http://www.git-scm.com/doc
E a página de ajuda em português tem várias informações necessárias para iniciantes no GitHub: https://help.github.com/pt
Um guia SUPER PRÁTICO: http://rogerdudler.github.io/git-guide/index.pt_BR.html
Um guia rápido, em inglês, porém excelente e enxuto: https://services.github.com/on-demand/downloads/github-git-cheat-sheet.pdf
E outro, também em inglês, totalmente interativo: http://ndpsoftware.com/git-cheatsheet.html#loc=workspace;
E mais esse (LEARN GIT IN AN INTERACTIVE WAY), interativo também, através dos comandos do git: https://wethefoss.github.io/Git-Commands/
Livro Pro Git, escrito por Scott Chacon e Ben Straub e publicado pela Apress, está disponível aqui. Todo o conteúdo está licenciado sob a licença Creative Commons Attribution Non Commercial Share Alike 3.0. https://www.git-scm.com/book/pt-br/v2
Para quem ainda tem dúvidas sobre os comandos do Git: https://gitexplorer.com/
Sinta-se a vontade para adicionar mais informações ou realizar correções. Fork me!