O git é o que chamamos, dentro do mundo de desenvolvimento/computação, um sistema de controle de versões, e é interessante que criemos o hábito de trabalhar com ele de forma minimamente eficiente, isso irá colaborar com um repositório de fácil leitura e compreensão (principalmente se formos trabalhar de forma colabotariva).
Como esse registro não tem o propósito de ensinar o passo a passo do git, e se você não souber absolutamente nada sobre, recomendo iniciar pelo Git Handbook (1) e depois pode dar uma olhada também nesse material do Learning Git Branching (2), e para testar para além do tutorial pode ser utilizado o Visualizing Git (3). Eles providenciarão uma boa visão sobre o básico-intermediário do git.
Um pouco do que está aqui embaixo é com base nesses dois materiais e também nesse documento Git Cheat Sheets (4) que pode ser impresso, só que aqui é uma forma rápida de entender como funcionaria um git workflow básico e que é o que fazemos quase todo dia.
Se você já tem um bom conhecimento sobre git, mas só trabalha no branch master, leia sobre como melhorar o fluxo de trabalho no git (5)
Para iniciar um repositório git é só digitar git init dentro do diretório que você quer que seja versionado.
Depois de realizar algumas alterações é possível registrar essas coisas no git, como você fez mudanças em arquivos será preciso ''readicionar'' esse arquivo ao git para que ele possa fazer o registro das alterações de forma correta git add <arquivo>
E então se faz o registro de fato da alteração realizada com o git commit
É uma boa prática, e existe algumas regras de como fazer um bom commit (6) git commit -m, --message
Se fizermos uma alteração no mesmo arquivo e não quisermos digitar uma nova mensagem, porque ela diz respeito a mesma coisa anterior, é só fazer o seguinte git commit -a, --ammend -m, --message ou somente git commit -am <mensagem>.
Usar branch deveria ser mandatório, por isso a primeira coisa que devemos fazer é criar um branch para o que vamos trabalhar.
Como não estamos trabalhando ainda com repositórios comunitários, não precisamos listar branches, mas depois vamos fazer isso, pois é possível que precisemos lidar com eles e conhecer outros branches. Assim o comando git branch
Lista os branches do repo. E se quisermos mudar para a branch git checkout <branch>
Mas na maioria das vezes vamos criar uma branch nova, para isso o comando git checkout -b <branch>
Cria a branch e já muda para a branch criada.
O git merge mescla um repositório em outro, o é que será mesclada
no branch atual exemplo para mesclar um branch dev na master, mudamos para o branch master git checkout master e mesclamos o que tem no branch dev no branch atual git merge dev e por fim git merge <branch>
O git rebase é uma forma mais fancy de mesclar as mudanças feitas nos commits. E podemos dizer que é a forma mais apropriada para tal. Usar o rebase ao contrário do merge faz com que as coisas fiquem cada um no seu lugar, e é um boa prática (7).
Vamos inicialmente criar um novo ramo (branch) git checkout -b bugFix
Supondo que você desenvolveu seu trabalho e resolve o bug, precisamos mesclar isso com o ramo master git rebase master
Mas agora o ramo bugFix está à frente da master, então vamos voltar para a master e mesclar as coisas do bugFix dentro dela.
git checkout master`
git rebase bugFix`
É possível também usar o modo interativo, passando o parâmetro -i ou --interactive git rebase --interactive bugFix
O git é essencialmente uma série de referências para aquilo que foi feito nos arquivos rastreados (tracked) e nós estamos sempre em algum commit específico, esse commit chamamos normalmente de HEAD, que fica sempre escondido por um branch ou por um hash. Existem duas formas de caminhar nos caminhos dos commits do git, uma é usando uma referência diretamente vizinha, ou seja, posicionando o HEAD no commit anterior com git checkout HEAD^. E outra é associando um branch a um commit muito distante, ou seja a três níveis acima ou mais, o que evita usar a referência de vizinho várias vezes, assim git branch -f <branch> HEAD~<n#> onde é o nome do ramo que você deseja mover para o <n#> do commit ou hash. É possível também mover o branch para um commit específico sem levar o HEAD junto, git branch -f <branch> <n#>.
Apesar de o git permitir o registro de tudo que é feito, às vezes alguma coisa sai errado ou do jeito que não queremos e precisamos reverter um commit. Existe um forma local e outra que permitir reverter as coisas diretamente na versão remota.
git reset HEAD~<n#> permite voltar para um commit específico como se reescrevesse a história, ignorando os commits subsequentes. Lembre que sempre é possível usar o hash do commit que desejar voltar.
git revert HEAD diferente do reset ele não "exclui" o commit e volta para um estado anterior, ele cria um novo commit com as mudanças que foram realizadas para aquele commit com o estado anterior. E da mesma forma que o reset é possível usar o hash do commit.
O git tem permite também copiar commits para compor uma nova linha do tempo. Com o git cherry-pick <n#> é possível copiar um ou mais commits e adicioná-los ao branch atual.
Já comentamos sobre o rebase antes, mas tem uma forma de realizar o rebase interativo, usando o argumento -i, --interactive.
A ideia é a mesma git rebase --interactive <branch> a diferança agora é que você tem a opção de fazer um cherry-pick definindo qual commit você vai incluir, ou um drop que vai dizer qual commit você não vai incluir no rebase ou até mesmo um squash que é quando juntamentos vários commits em um novo para ficar mais agradável de mesclar posteriormente (inclusive o log vai ficar mais bonito).
echo "# github-learning-lab" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:mchagas/github-learning-lab.git
git push -u origin master
echo "# github-learning-lab" >> README.md
git init
git add README.md
git commit -m "primeiro commit"
git remote add origin [email protected]:mchagas/github-learning-lab.git
git push -u origin master
- Documentação oficial Git
- Gist @guimaluf que serviu de base/incentivo para esse gist.