Introdução:

Com toda certeza você já foi uma vez na documentação do git e se deparou com um grande livro (realmente gigante) de vários comandos do git. Apesar de existirem muitos comandos, nem todos são utilizados com frequência. Neste Artigo eu trago alguns dos comandos mais utéis no dia a dia e algumas dicas de como resolver problemas como consertar um commit, junto com uma extensão bem legal para o Vscode.

Posts semelhantes:

Existem alguns posts aqui no tabnews que já falam sobre isso, caso queiram alternativas a este meu, listarei todos que eu encontrei sobre:

Esses foram alguns dos principais que eu encontrei após uma rápida navegada no tabnews, entretanto ainda existem outros.

Observações

Já partirei do presuposto de que você já está logado no git usando o git auth ou qualquer outro meio que você utilizou.

Inicializando um repositório

Sendo o comando mais simples do git, o git init inicializa um repositório. Então supondo que você queira inicializar um projeto novo, escolha alguma pasta vazia (ou alguma já pronta mesmo, caso queira apenas implementar o git) e digite o comando git init que será adicionado todos os arquivos necessários para o git fazer o versionamento.

Se você é do windows, talvez não encontre a pasta dos arquivos, pois ela esta oculta. Caso tenha interesse em abrir e ver o que tem dentro da pasta do git, basta da uma rápido pesquisada sobre como mostrar pastas ocultas no windows.

Estágios do git (plus)

Para você que já conhece os estágios do git, pode pular esta parte. Será apenas um embasamento simples sobre os estágios do git para quem não conhece ou ainda tem dúvidas.

Existem 3 estágios ao utilizar o git. O primeiro deles é o working directory que é quando estamos trabalhando no código sem nada esta versionado. Nesse estágio todas as nossas alterações não serão refletidas no código que já está no repositório remoto, ao menos que você mesmo queira isso.

O outro estágio é o stage que é onde os arquivos já está guardado em um lugar especial (mas ainda não foram para um servidor) pelo o git. O stage indica que quando fizermos um commit, todos os arquivos do stage serão enviados para o repositório remoto.

O último estágio é o: git repository onde seu código já foi commitado e já está armazenado em um servidor.

Adicionando arquivos para o stage

Antes de mostrar como funciona o commit, demonstrarei como levar os arquivos para o stage.
Para levar um arquivo para o stage use o seguinte comando: git add <file> onde <file> é o arquivo que você quer adicionar. Por exemplo: git add index.html

Para saber quais arquivos ainda não foram commitados use o git status

Caso você tenha muitos arquivos para digitar manualmente um por um, utilize o seguinte comando para levar seus arquivos para o stage: git add . onde todos os arquivos que sofreram uma alteração será colocado em um lugar especial e serão preparados para um commit.

Caso você queira apenas adicionar arquivos de apenas uma determinada extensão: git add *.css levará para o stage todos os arquivos que terminam com .css.

Caso tenhamos um código já no stage, e sem querer alteramos esse código que estava pronto para ser commitado, e queremos que volte a ser ao que era na versão do stage, utilize o seguinte comando git restore index.html.

O Comando git diff é muito útil para mostrar as diferenças de um estágio para o outro. Caso queria ver de um arquivo em particular, basta escrever o seguinte comando: git diff <file> onde <file> é o nome do seu arquivo, como por exemplo: git diff index.html.

Commitando arquivos

commits é uma das coisas mais importantes do git, senão a mais importante. Um commit contém algumas características que listarei abaixo:

Commits leval as alterações do código para um servidor remoto
Commits possui um identificado único (hash)
Metadados para saber a autoria do commit
Uma mensagem para identificar a motivação da alteração

Para commitar todos os arquivos que estão no stage para um servidor remoto use o seguinte comando git commit -m "sua mensagem. Caso queira detalhar mais a mensagem e descrição do commit, escreva git commit apenas e irá abrir um arquivo no seu Vscode onde você pode digita o nome do commit e dar mais detalhes com uma descrição.

Se quiser agilizar o processo e fazer um commit mais rápido sem passar pelo o stage use o seguinte comando: git commit -a -m "sua mensagem" onde pulará a etapa de adicionar ao stage

Observação

MAS CUIDADO! ARQUIVOS CRIADOS QUE AINDA NÃO ESTÃO NO GIT, NÃO SERÃO ENVIADO COM O COMANDO git commit -a -m "sua mensagem" POR EXEMPLO: EU TENHO UM PROJETO DO ZERO, CRIEI 3 ARQUIVOS, E AGORA QUE FIZ TUDO O QUE QUERIA, QUERO COMMITAR, PORÉM AO UTILIZAR O COMANDO git commit -a -m "sua mensagem" OS ARQUIVOS NÃO SERÃO ENVIADOS POIS ELES NUNCA ESTIVERAM NO GIT. ESSE COMANDO SÓ FUNCIONA SE EM ALGUM MOMENTO, VOCÊ ADICIONOU OS ARQUIVOS NO GIT AO MENOS UMA VEZ. POR EXEMPLO, SUPONDO QUE AINDA TENHO ESSES 3 ARQUIVOS SEM SER COMMITADOS E NEM LEVADOS AO STAGE, EU PRIMEIRO ADICION ELE COM O SEGUINTE COMANDO git add . E FAÇO UM COMMIT NORMAL. DEPOIS EU VOLTO E ALTERO ESSES ARQUIVOS, AI SIM EU POSSO UTILIZAR O git commit -a -m "sua mensagem" POIS OS ARQUIVOS QUE EU ESTOU ALTERANDO JÁ PASSARAM PELO O STAGE PELO MENOS UMA VEZ.

Consultando logs

É muito importante dar uma atenção a esses comandos, pois eles nos permite verificar a autoria de commits, dentre outras coisas. Usando o comando git log irá lista todoso os commits feitos com datas, nome do autor, e etc... Isso é muito importante para verificar a integridade do projeto, ver quem fez o último commit e etc.

Caso seu repositório tenha muitos commmits, e você queira limitar a um determinado número, você pode usar algo como git log -3 onde o -3 indica a quantidade de elementos que eu quero ver . Neste caso me retornaria uma lista dos 3 últimos commits. Poderia ser qualquer número.

Caso queira ver uma lista de commits mais simplificada, utilize: git log --oneline. Outra forma de ver commits é com o seguinte comando: git log --graph. Também é possível misturar os comando e ter algo como: git log --oneline --graph.

Caso queria filtrar todos os commits de um determinado autor: git log --author="nome do autor". Existe uma forma ainda mais curta de ver os commits usando o comando: git shortlog onde vai mostrar o autor, e abaixo todos os seus commits de sua autoria.

Com o comando git reflog podemos verificar todas as ações em um repositório.

Branches

Branches são como um espaço em nosso projeto que podemos trabalhar sem afetar o código principal. Então supondo que eu tenho meu código principal funcionando em produção (branch main). Ai queremos testar uma nova funcionalidade, mas não podemos colocar em risco da aplicação que já funciona parar de funcionar. Neste caso, criamos uma branch, que é como uma cópia do nosso código principal, mas lá podemos editar qualquer coisa sem afetar o que já está funcionando.

Para saber qual Branch estamos, digitamos o comando git branch que por padrão é a branch main ou master.

Criando branches

É muito simples criar uma branch nova, basta digitar o seguinte comando:
git branch nome-da-branch

Exemplo: git branch feature cria uma branch com o nome feature. Perceba que aparece um asterisco que serve para indicar onde estamos trabalhando atualmente.

Existe uma alternativa ao comando git branch nome-da-branch que é o:
git checkout -b feature onde feature é o nome dado para a branch, mas poderia ser qualquer outro. Essa forma além de criar uma nova branch, ele automaticamente já vai para dentro desta branch. Caso a branch já exista, apenas vai trocar a branche atual pela a qual você especificou

Excluindo branches

Para excluir uma Branch, é muito simples. O comando e o seguinte:
git branch -D feature que vai excluir a branch feature. Basta trocar o nome "feature" para o nome da branch que você quer apagar.

Alterando o nome de uma branch

é possível alterar o nome da branch atual ao utilizar o seguinte comando:
git branch -m novo-nome

Consultando logs de uma branch

É possível ver o log de uma Branch específica com o seguinte comando:
git log nome-da-brach que irá aparecer o log de tudo da branch

Merge

Ao criar uma branch nova e ir trabalhando nela, eventualmente temos que pegar essa branch e mesclar ela junto com a branch principal (main). Para fazer isso é bem simples:

Mude para a branch principal com o comando git checkout main. Esse comando vai fazer você ir para a Branch main. Além disso, esse comando cria uma branch nova, caso ela não exista. Se existir, vai apenas trocar de branch.

Depois disso adicione o comando: git merge nome-da-brach que você quer mesclar.

As vezes podem ocorrer problemas de conflitos com os arquivos. Quando isso acontece temos que resolver tudo manualmente. Mas logo de cara podemos dar um git merge --abort para abortar o merge e resolver os conflitos antes.

Dicas sobre commits convencionais:

das regras da convenção, temos os seguintes tipos:

test: indica qualquer tipo de criação ou alteração de códigos de teste. Exemplo: Criação de testes unitários.
feat: indica o desenvolvimento de uma nova _feature a_o projeto. Exemplo: Acréscimo de um serviço, funcionalidade, endpoint, etc.
refactor: usado quando houver uma refatoração de código que não tenha qualquer tipo de impacto na lógica/regras de negócio do sistema. Exemplo: Mudanças de código após um code review
style: empregado quando há mudanças de formatação e estilo do código que não alteram o sistema de nenhuma forma.
Exemplo: Mudar o style-guide, mudar de convenção lint, arrumar indentações, remover espaços em brancos, remover comentários, etc..
fix: utilizado quando há correção de erros que estão gerando bugs no sistema.
Exemplo: Aplicar tratativa para uma função que não está tendo o comportamento esperado e retornando erro.
chore: indica mudanças no projeto que não afetem o sistema ou arquivos de testes. São mudanças de desenvolvimento.
Exemplo: Mudar regras do eslint, adicionar prettier, adicionar mais extensões de arquivos ao .gitignore
docs: usado quando há mudanças na documentação do projeto.
Exemplo: adicionar informações na documentação da API, mudar o README, etc.
build: utilizada para indicar mudanças que afetam o processo de build do projeto ou dependências externas.
Exemplo: Gulp, adicionar/remover dependências do npm, etc.
perf: indica uma alteração que melhorou a performance do sistema.
Exemplo: alterar ForEach por while, melhorar a query ao banco, etc.
ci: utilizada para mudanças nos arquivos de configuração de CI.
Exemplo: Circle, Travis, BrowserStack, etc.
revert: indica a reverão de um commit anterior.

Observações:

Só pode ser utilizado um type por commit;
O type é obrigatório;
Caso esteja indeciso sobre qual type usar, provavelmente trata-se de uma grande mudança e é possível separar esse commit em dois ou mais commits;
A diferença entre build e chore pode ser um tanto quanto sutil e pode gerar confusão, por isso devemos ficar atentos quanto ao tipo correto. No caso do Node.js por exemplo, podemos pensar que quando há uma adição/alteração de certa dependência de desenvolvimento presente em devDependencies, utilizamos o chore. Já para alterações/adições de dependências comuns aos projeto, e que haja impacto direto e real sobre o sistema, utilizamos o build.

Este texto não é de minha autoria, eu apenas copiei e colei para agilizar o processo do site: conventional commits

Consertando erros:

Errar é humano, dito isso, pode custar nossos empregos ou gerar uma dor de cabeça enorme. Listarei algumas formas de resolver esses erros:

Retornando ao estado do commit

Se o arquivo ainda não foi commitado, mas foi alterado, podemos fazer o seguinte:

Digite o comando git checkout -- nome-do-arquivo

Exemplo prático: git checkout -- index.html

Fazendo isso seu arquivo vai voltar para o estado que estava no último commit.

desfazendo erros do stage

Use o seguinte comando para reverter o que está no stage:
git reset --hard HEAD que vai retornar para o estágio anterior (antes do commit)

Consertando um commit:

Para desfazer commits, não é tão difícil assim. Você pode desfazer 1 commit. Não tenho certeza se é possível desfazer mais de 1 ao mesmo tempo (ficarei devendo essa).

O comando é o seguinte: git reset --hard HEAD~1

Consertando a mensagem do commit:

Supondo que eu errei a mensagem de um commit, eu posso consertar.

digite o seguinte comando: git commit --amend

Vai abrir um arquivo, que permite você editar a mensagem. Após fechar o arquivo, vai atualizar a mensagem para o que você escreveu.

é possível alterar além de um commit anterior, mas de um jeito diferente. Pegue o hash do commit.

Comando git revert hash

Isso cria um commit novo, se eu não me engano, logo, não erre.

transferindo alterações entre branches

Se estivermos trabalhando em uma branch que não era para está, mas já alteramos muita coisa, podemos criar um stash. stash nada mais é que um lugar especial que guarda nossas alterações.

Então use o seguinte comando: git stash

Ele vai guardar todas as alterações em um lugar especial. Ai mude de branch que você quer aplicar essas alterações. e use o comando:
git stash apply que vai aplicar as alterações. Mas há um problema. Utilizar o git stash apply mantém as mudanças guardadas no stash ainda, para caso queiramos usar novamente depois. Caso não seja isso que você quer, use o comando git stash pop que vai aplicar as alterações, e vai remover do stash.

Use o git graph

Git graph é uma extensão que mostra o andamento dos commits em nosso projeto, tornando muito mais facil navegar e rastrear commits. Uma imagem de como ele é mais ou menos:

ilustration

Além disso possui outras funcionalidade interessantes. Ao clicar em um commit, ele mostrará informações adicionais sobre o commit em particular.

Conclusão:

É isso pessoal. Gostaram? Cometi algum erro? Comentem!

[ Conteúdo ] Alguns dos mais essenciais comando do Git + Dicas de como reverter suas cacas e escrever melhores commits