Aqui estão todos os comandos Git que usei na última semana, e o que eles fazem.

Créditos da imagem: GitHub Octodex

Como muitos novatos, comecei pesquisando por comandos Git pelo StackOverflow, e então copiando-colando as respostas, sem entender realmente o que eles faziam.

Créditos da imagem: XKCD

Me lembro de pensar, “Não seria legal se houvesse uma lista dos comandos Git mais comuns, juntamente com uma explicação do porquê eles são úteis?”

Bom, aqui estou anos depois para compilar tal lista, e explanar algumas boas práticas que mesmo desenvolvedores de nível intermediário-avançados podem achar úteis.

Para certificar que seja prática, estou baseando esta lista dos comandos Git que eu realmente usei ao longo da semana passada.

Praticamente todo desenvolvedor usa o Git, e principalmente o GitHub. Mas o desenvolvedor médio provavelmente usa apenas estes três comandos 99% do tempo:

git add --all
git commit -am "<message>"
git push origin master

Funcionam perfeitamente bem quando você está trabalhando em um time individual, em um hackathon, ou em um app apenas por diversão, mas quando estabilidade e manutenção começam a se tornar uma prioridade, commits claros, estabelecer uma estratégia de branching, e escrever mensagens de commit coerentes se torna importante.

Começarei esta lista com os comandos comumente usados para torná-la mais fácil para que os novatos entendam o que é possível com o Git, e então continuá-la através das funcionalidades mais avançadas e das boas práticas.

Comandos regularmente usados

Para inicializar o Git em um repositório (repo), você só precisa digitar o comando a seguir. Se você não inicializar o Git, você não pode rodar nenhum outro comando Git dentro daquele repositório.

git init

Se você está usando o GitHub e está subindo o código para um repositório online, você está usando um repositório remoto. O nome padrão (também conhecido como alias) para este repositório remoto é origin. Se você copiou um projeto do GitHub, ele já tem uma origin. Você pode ver esta origin com o comando git remote -v, que listará a URL do repositório remoto.

Se você inicializou seu próprio repositório Git e quer associá-lo com um repositório no GitHub, você deve criar um no GitHub, copiar a URL fornecida, e usar o comando git remote add origin <URL>, com a URL fornecida pelo GitHub substituindo “<URL>”. Agora, você já pode adicionar arquivos e pastas, commitar, e dar push em seu repositório remoto.

O último é usado quando você precisa mudar o repositório remoto. Digamos que você copiou um repositório de alguém e quer mudar o repositório remoto do dono original para sua própria conta no GitHub. Siga o mesmo processo do git remote add origin, e então use set-url para mudar o repositório remoto.

git remote -v
git remote add origin <url>
git remote set-url origin <url>

O jeito mais comum de copiar um repositório é usando o git clone, seguido pela URL do repositório.

Tenha em mente que o repositório remoto estará linkado com a conta da qual você clonou o repositório. Se você clonou um repositório que pertence a alguma outra pessoa, você não estará apto a dar push para o GitHub até que você mude a origin usando os comandos acima.

git clone <url>command

Você rapidamente começará a usar branches. Se você não sabe o que branches são, há outros tutoriais muito mais aprofundados, e você deve lê-los antes de continuar (aqui está um deles — em inglês).

O comando git branch lista todas as branches de sua máquina local. Se você quer criar uma nova branch, você pode usar git branch <nome>, onde <nome> representa o nome da branch, como “master”.

O git checkout <nome> alterna para uma branch existente. Você pode ainda usar o comando git checkout -b <nome> para criar uma nova branch e imediatamente alternar para ela. A maioria das pessoas usa este comando ao invés dos comandos branch e checkout separados.

git branch
git branch <nome>
git checkout <nome>
git checkout -b <nome>

Se você fez várias mudanças em uma branch, vamos chamá-la “desenvolvimento”, e quer mesclá-la com a sua branch master, utilize o comando git merge <branch>. Você precisará dar checkout em sua branch master, e então entrar com git merge develop para mesclar “desenvolvimento” com a branch master.

git merge <branch>

Se você está trabalhando com várias pessoas, haverá um momento onde o repositório foi atualizado no GitHUb, mas você não tem as mudanças localmente. Se este é o caso, você pode usar o comando git pull origin <branch> para empurrar as mudanças mais recentes para a branch remota.

git pull origin <branch>

Se você está curioso pra saber que arquivos foram mudados e o que está sendo registrado, você pode usar o comando git status. Se você quiser ver quanto cada arquivo foi mudado, pode usar git diff para ver o número de linhas mudadas em cada arquivo.

git status
git diff --stat

Comandos avançados e boas práticas

Logo você chegará a um ponto em que você quer que seus commits pareçam legais e continuem consistentes. Você talvez tenha também que mexer em seu histórico de commits para torná-los mais simples de compreender ou para reverter uma mudança que acidentalmente quebrou a lógica de commit.

O comando git log permite ver o histórico de commits. Você vai querer usar isto para ver seu histórico de commits.

Seus commits virão com mensagens e um hash, que é uma série aleatória de números e letras. Por exemplo, um hash pode parecer com isto: c3d882aa1aa4e3d5f18b3890132670fbeac912f7

git log

Digamos que você deu push em algo que bugou seu aplicativo. Ao invés de arrumar e dar push novamente, você deve voltar um commit e fazê-lo novamente.

Se você quer voltar no tempo e recomeçar seu app de um commit anterior, você pode fazê-lo diretamente usando o hash como o nome da branch. Isto irá desvincular seu app da versão atual (porque você estará editando um registro do histórico, ao invés da versão corrente).

git checkout c3d88eaa1aa4e4d5f

Então, se você fez mudanças na branch daquele registro e quer dar push de novo, você deve fazer um push forçado.

Atenção: Pushes forçados são perigosos e devem ser feitos apenas se não houver opção. Ele irá sobrescrever todo o histórico do seu app e você irá perder tudo que veio depois daquele ponto.

git push -f origin master

Outras vezes apenas não é prático manter tudo num commit. Talvez você quer salvar seu progresso antes de tentar algo potencialmente arriscado, ou talvez você cometeu um erro e quer se poupar do constrangimento de haver um erro em seu histórico de versionamento. Para isto, temos o git rebase.

Digamos que você tem quatro commits em seu histórico local (sem push pro GitHub) no qual você fez e desfez várias alterações. Seus commits parecem desastrados e indecisos. Você pode usar o rebase para combinar todos estes commits em um único, mais conciso.

git rebase -i HEAD~4

O comando acima irá abrir o editor padrão de seu computador (que é o Vim, a menos que você tenha alterado), com diversas opções de como você pode mudar seus commits. Aparecerá algo parecido com o código abaixo:

pick 130deo9 oldest commit message
pick 4209fei second oldest commit message
pick 4390gne third oldest commit message
pick bmo0dne newest commit message

No intuito de combinar estes commits, precisamos mudar a opçao “pick” por “fixup” (como a documentação abaixo do código diz) para fundir os commits e descartar as mensagens deles. Note que no Vim você precisa pressionar “a” ou “i” para estar apto a editar o texto, e para salvar e sair, precisa apertar Esc e então “Shift + z + z”. Não me pergunte o porquê, apenas é assim.

pick 130deo9 oldest commit message
fixup 4209fei second oldest commit message
fixup 4390gne third oldest commit message
fixup bmo0dne newest commit message

Isto irá mesclar todos os seus commits dentro do commit com a mensagem “oldest commit message”.

O próximo passo é renomear sua mensagem de commit. É uma questão de opinião, mas desde que você siga um padrão consistente, qualquer coisa que vocẽ faça está bem. Eu recomendo usar as commit guidelines postas pelo Google para Angular.js (em inglês).

Para mudar a mensagem de commit, use o parâmetro amend.

git commit --amend

Isto também abrirá o Vim, e as regras de edição de texto e salvamento são as mesmas acima. Para dar um exemplo de uma boa mensagem de commit, aqui está uma que segue as regras da guideline:

mudança: adicionar botão de checkout para a paǵina de pagamentos
- adiciona botão de checkout
- escreve testes para checkout

Uma vantagem de manter os tipos de alteração listados na guideline é que isso torna mais fácil a escrita de logs de mudança. Você também pode incluir informações no footer (novamente, especificado na guideline) que faça referências a issues.

Note: você deve evitar reescrever seus commits se você está colaborando em algum projeto e tem código no GitHub. Se você muda o histórico de versionamento sem o consentimento alheio, pode acabar tornando a vida de todos mais difícil com bugs que são complicados de rastrear.

Há um número quase infinito de comandos possíveis com Git, mas estes comandos são provavelmente os únicos que você precisa saber para os primeiros anos de programação.

Here are all the Git commands I used last week, and what they do, por Sam Corcos. Disponível aqui.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.