Aqui estão todos os comandos do Git que usei na semana passada e o que eles fazem

Artigo original: https://www.freecodecamp.org/news/git-cheat-sheet-and-best-practices-c6ce5321f52/

Escrito por: Sam Corcos

Como a maioria dos novatos, comecei procurando no StackOverflow por comandos do Git, copiando e colando as respostas, sem realmente entender o que eles faziam.

Lembro-me de pensar, "Não seria ótimo se houvesse uma lista dos comandos mais comuns do Git com uma explicação de para que eles são usados?"

Bem, anos depois, aqui estou eu compilando esta lista e apresentando algumas práticas recomendadas que até mesmo desenvolvedores intermediários e avançados devem achar úteis.

Para manter as coisas práticas, estou baseando esta lista em comandos reais do Git que usei na semana passada.

A maioria dos desenvolvedores hoje em dia usa o Git e, muito provavelmente, o GitHub também. Porém, um desenvolvedor intermediário provavelmente usa apenas esses três comandos 99% das vezes:

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

Isso é ótimo quando você está trabalhando em um time de uma pessoa só, em um hackathon ou em um aplicativo "descartável". Mas quando a estabilidade e a manutenção começam a ser prioridade, fazer commits organizados, seguir uma estratégia de ramificação e escrever mensagens consistentes de commit se tornam muito importantes.

Vou começar com a lista de comandos comumente usados ​​para tornar mais fácil aos iniciantes entender o que é possível com o Git e, só depois, passar para recursos mais avançados e melhores práticas.

Os comandos mais usados

Se você não inicializar o Git, não poderá executar os outros comandos do Git nesse repositório. Por isso, para inicializar o Git em um repositório (ou repo, para os mais chegados, hehe), basta digitar o seguinte comando:

git init

Se você estiver usando o GitHub e enviando (também chamado de fazendo um push) o código para um repositório do GitHub on-line, você está usando um repositório remoto. O nome (também conhecido como alias) padrão para este repositório remoto é origin. Se, no entanto, você copiou esse projeto do Github, ele já tem um origin. Você pode ver a localização desse repositório usando o comando git remote -v, que exibe o URL do repositório remoto.

Se você inicializou seu próprio repo do Git e deseja vinculá-lo a um repo do GitHub, precisa primeiro criá-lo no GitHub, copiar o URL gerado e usar o comando git remote add origin <URL>, com o URL do GitHub substituindo o "<URL>". A partir daí, você pode adicionar arquivos, fazer os commits das alterações, além de enviá-los com o push para o seu repositório remoto.

Este último comando é utilizado também quando você precisa alterar algo do repo remoto. Por exemplo, suponhamos que você copiou o repo de outra pessoa e deseja alterar a origem do repositório remoto dela para o da sua própria conta do GitHub. É o mesmo procedimento do git remote add origin, porém você altera o URL no set-url para mudar de repositório remoto original.

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

Só tenha em mente que o repositório remoto será vinculado à conta de onde você o clonou. Portanto, se você clonou esse repo de outra pessoa, não conseguirá fazer o push para o GitHub até alterar a origin usando o comando acima.

A maneira mais comum de clonar um repositório é usar git clone, seguido do URL do repositório.

git clone <url>

Após isso, logo você estará usando branches (ramificações). Se você não entende o que elas são, existem outros tutoriais muito mais aprofundados, e você deve lê-los antes de prosseguir (aqui temos um, em inglês).

Se você quiser criar uma nova branch, você pode usar git branch <nome>, com <nome> representando o nome da branch, como, por exemplo, "master". Com o comando git branch, você lista todas as branches do repositório local.

Já o comando git checkout <name> alterna para outra branch existente. Você pode também usar o comando git checkout <name> para criar uma nova branch e imediatamente mudar para ela. A maioria das pessoas usa isso em vez de comandos separados de branch e checkout.

git branch
git branch <name>
git checkout <name>
git checkout -b <name>

Se você fez muitas mudanças em uma branch, que vamos chamar de "develop", e se quiser fazer o merge de seus arquivos da branch de volta ao master, você usa o comando git merge <branch>.  Você primeiro faz o checkout para a branch master e, em seguida, executa git merge develop para fazer o merge de develop na branch master .

git merge <branch>

Se você está trabalhando com muitas pessoas, e se estiver em uma posição onde o repo foi atualizado no GitHub, mas não mudou localmente, pode usar git pull origin <branch> para receber as mudanças mais recentes  da sua branch remota.

git pull origin <branch>

Se estiver curioso para ver quais arquivos foram alterados e quais o Git está monitorando, use git status. Já se quiser ver o quanto cada arquivo foi alterado, você pode usar o comando git diff para ver o número de linhas alteradas em cada arquivo.

git status
git diff --stat

Comandos avançados e práticas recomendadas

Em pouco tempo, você chegará ao patamar em que desejará que seus commits tenham uma boa aparência e permaneçam consistentes. Você também poderá ter de mexer no seu histórico de commits para torná-los mais fáceis de compreender ou, ainda, reverter uma alteração acidental.

Para isso, você vai precisar usar o comando git log, que permite a você ver o histórico de commits.

Ah, e seus commits sempre virão com mensagens e um hash, que é uma série aleatória de números e letras. Um hash pode ser assim: c3d882aa1aa4e3d5f18b3890132670fbeac912f7

git log

Vamos dizer que você subiu algo para o GitHub que quebrou seu aplicativo. Em vez de corrigi-lo e enviar algo novo, você prefere apenas voltar um commit e tentar novamente.

Se você quiser voltar no tempo e fazer o checkout do seu aplicativo de um commit anterior, você pode fazer isso diretamente usando o hash como o nome da branch. Isso separará seu aplicativo da versão atual (porque você está editando um registro histórico, em vez da versão atual).

git checkout c3d88eaa1aa4e4d5f

Então, se você fizer alterações no histórico da sua branch e quiser fazer o push novamente, terá que fazer um push forçado.

Cuidado: fazer o push com esse método forçado é perigoso e só deve ser feito se for absolutamente necessário. Ele substituirá o histórico do seu aplicativo e você perderá o que veio depois.

git push -f origin master

Às vezes, também não é prático manter tudo em um commit só. Talvez você queira salvar seu progresso antes de tentar algo potencialmente arriscado, ou talvez tenha cometido um erro e queira se poupar do constrangimento de ter um erro no seu histórico de versões. Para isso, temos o git rebase.

Digamos que você tenha 4 commits em seu histórico local (não enviado para o GitHub) nos quais você foi e voltou. Seus commits agora parecem desarrumados e indecisos. Você pode usar o rebase para combinar todos esses commits em um único commit conciso.

git rebase -i HEAD~4

O comando acima abrirá o editor de texto padrão do seu computador (a menos que você o tenha configurado para outro editor, provavelmente será para o Vim), com várias opções de como você pode alterar seus commits. Será algo como 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

Para combiná-los, precisamos alterar a opção “pick” para “fixup” para mesclar os commits e  descartar as mensagens de commit. Note que no Vim, você pressiona "a" ou "i" para poder editar o texto, salvá-lo e sair, você precisa digitar a tecla Esc seguida de "shift + z + z". Não me pergunte o motivo, apenas é assim.

pick 130deo9 mensagem de commit mais antiga
fixup 4209fei segunda mensagem de commit mais antiga
fixup 4390gne terceira mensagem de commit mais antiga
fixup bmo0dne mensagem de commit mais nova

Isso mesclará todos os seus commits em um só commit com a mensagem "mensagem de commit mais antiga".

O próximo passo é renomear sua mensagem de commit. Mas isso é só questão de opinião, pois desde que você siga um padrão consistente, tudo o que você fizer está bem. Eu recomendo usar as regras e diretrizes do Google feitas para o Angular.js (texto em inglês).

Para mudar a mensagem do commit, use a flag amend.

git commit --amend

Isso também abrirá o Vim, e as regras de salvamento e edição de texto são as mesmas de cima. Como exemplo de uma boa mensagem de commit, abaixo vemos uma mensagem que segue as diretrizes citadas anteriormente:

feat: add stripe checkout button to payments page

- add stripe checkout button
- write tests for checkout

Uma vantagem de manter os tipos listados na diretriz é que isso facilita a gravação de logs de alterações. Também é possível incluir informações no rodapé (novamente, especificadas na diretriz) que referenciam os problemas.

Nota: você deve evitar fazer o rebase ou compactar seus commits se estiver colaborando em um projeto e tiver código enviado para o GitHub. Se você começar a alterar o histórico de versões debaixo do nariz das pessoas, pode acabar dificultando a vida de todos com bugs difíceis de rastrear.

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

Sam Corcos é o principal desenvolvedor e cofundador do Sightline Maps, uma plataforma intuitiva para impressão 3D de mapas topográficos, e também do LearnPhoenix.io, um site de tutoriais intermediários-avançados para a criação de aplicativos de produção escaláveis ​​com Phoenix e React.