Comandos básicos do Git

init

• Estrutura: git init
• Descrição: Todas mudanças realizadas versionadas com o git ficam na pasta .git na raiz do projeto. Para ter esse diretório - e consequentemente utilizar o git - das duas uma, ou clona um objeto (baixa um existente) com git clone <endereco> ou inicializa o git na pasta com init
• Flags:
  • git init --bare inicia servidor remote

clone

• Estrutura: git clone <url ou path>
• Descrição: Copia e cola projeto de acordo com a url
• Flags:
  • git clone --single-branch --branch <branch> <url> clona somente uma branch
• Observações:
  • git clone <url ou path> <diretorio> cria projeto com nome de pasta diferente do original

status

• Estrutura: git status
• Descrição: Verifica a situação dos arquivos do projeto deve-se utilizar.

add

• Estrutura: git add <file> <file> ...
  • <file> é um arquivo ou diretório, caso seja usado . adiciona tudo do atual diretório
• Descrição: Somente arquivos staged podem ser commitados, e para isso é preciso escolher untrackeds ou not stageds. Com add é feita a troca de estado para staged.
• Flags:
  • git add -A adiciona todos arquivos
• Observações:
  • git reset <file> troca de staged para untracked ou not staged

commit

• Estrutura: git commit
• Descrição: O commit é o responsável por gravar as alterações dos arquivos stageados no projeto. É pelo histórico de commits que é possível retroceder até determinada versão do projeto. Os principais características que todo commit possui é seu hash (identificador), data, autor e mensagem. Com o comando é aberto um editor de texto para escrever a mensagem.
• Flags:
  • git commit -m "<mensagem>" cria commit sem abrir o editor de texto
• Observações:
  • Dicas para uma mensagem de commit:
    • Ser clara para tornar fácil o entendimento do histórico do projeto.
    • Possuir um título descritivo de até 50 caracteres. Se necessário especificar mais, deve-se pular uma linha e descrever parágrafos de até 70 caracteres (caso prefira listar tópicos, utilize hifens).
    • Utilizar verbos no imperativo sobre o que aquele commit afeta no código. Exemplo: ao invés de escrever “Eu adicionei teste X” ou “Adicionando teste X”, use “Adiciona teste X”.
    • Vale ressaltar que podem existir convenções para mensagens de commits. Uma famosa é do site conventionalcommits.org, cujo foi adaptada para o framework angular.

remote

• Estrutura: git remote <comando>
  • <comando> comandos relacionados ao remote
    • git remote add <nome remoto> <url> adiciona <nome remoto>, sendo normalmente origin ou upstream
• Descrição: O Github hospeda projetos git online. Quando um projeto possui seu código salvo como no Github, ele possui um remote. Ao criar um projeto o git não sabe identificar aonde ele será “guardado”. Um projeto pode ter inúmeros remotes e comumente o seu principal é chamado de origin e o original de um fork upstream.
• Flags:
  • git remote -v exibe nomes dos remotes e suas urls

push

• Estrutura: git push <remote> <branch>
  • <remoto> nome do remote, normalmente origin ou upstream
  • <branch> branch do remote
• Descrição: Envia o código juntamente com seu histórico para o remote.

log

• Estrutura: git log
• Descrição: Lista os commits, podendo ser usado abaixo:
• Flags:
  • git log --pretty=oneline exibe cada commit em uma linha

merge

• Estrutura: git merge <branch nova>
• Descrição: Mescla duas branches. Caso nenhum commit tenha sido criado na branch de origem durante os commits da nova branch, o git vai juntar todos os commits diretamente (sem um novo commit com separação e referência da branch). Essa situação é uma funcionalidade do git chamada fast-forward.
• Flags:
  • git merge <branch> --no-ff junta branch atual com <branch> sem a opção de fast-forward

Prós e contras de fast-forward pelo criador do gitflow

checkout

• Estrutura: git checkout <referência>
  • <referência> branch, hash do commit ou arquivo/folder precedido de --
• Descrição:
  • Troca de branch
  • Acessa commit (transformando-o em uma branch temporária -ideal para inspecionar estado do projeto naquele ponto).
  • Descarta modificações de um arquivo não commitado
  • se <referência> for usada como git checkout <remote-branch>:<new-branch> é possível criar branch local a partir do remote (veja fetch para obter branches remotas).
• Flags:
  • git checkout -b <nova branch> cria <nova branch> e troca para a esta.
  • git checkout -- <arquivo ou folder> desfaz modificações não commitadas do arquivo/folder. Igual ao git restore <arquivo ou folder>. Para o folder atual, tanto checkout -- quanto restore, se for usado . é escolhido o diretório atual.

reset

• Estrutura: git reset <referência>
  • <referência> hash do commit, a posição relativa ao HEAD (sendo um anterior HEAD~1, dois HEAD~2 e etc) ou um arquivo para remover da área de staged.
• Descrição: Retorna o histórico ou altera a área de staged. Todos arquivos dos commits apagados permanecem (como modified ou untracked).
• Flags:
  • git reset --hard HEAD~1 desfaz todas alterações dos arquivos, não deixando modifieds ou untrackeds

bisect

• Estrutura: git bisect <comando>
  • <comando> comandos relacionados ao bisect
    • git bisect start inicia a procura pelo commit
    • git bisect bad especifica que o commit atual é ruim
    • git bisect good <hash-commit> especifica o commit bom, para o git procurar entre as duas especificações o responsável
    • git bisect reset encerra o monitoramento
• Descrição: Encontra o commit que adicionaram código com bug, substitui o uso do git checkout <hash-commit> por agilizar o processo de troca de commit. Funciona como uma sequencia interativa de troca de comunicação entre o algoritmo do git e o comportamento que está sendo analisado. é quase um quente ou frio
• Fluxo:
  1. git bisect start inicia a procura pelo commit
  2. git bisect bad especifica que o commit atual é ruim
  3. git bisect good <hash-commit> especifica o commit bom, para o git procurar entre as duas especificações o responsável
     • caso não saiba o commit bom, faça git checkout <hash-commit> até encontrá-lo, e quando achar use git bisect good
  4. o git vai te trocar de commit a cada git bisect good ou git bisect bad até sobrar 1, portanto cabe a você monitorar
  5. no commit que o git constatar ser o culpado será exibido em tela como “o primeiro commit ruim”
  6. git bisect reset para encerrar o monitoramento

  com git log é possível saber em que commit está para aprovar ou não (é a HEAD)

fetch

• Estrutura: git fetch
• Descrição: Atualiza as referências das branches dos remotes
• Observações:
  • git fetch <remote> <branch> retorna as referências especificas de uma branch de um remote
    • Após trazer a referência é possível ir para essa branch com git checkout <branch>

pull

• Estrutura: git pull <remoto> <branch>
  • <remoto> nome do remote, normalmente origin ou upstream
  • <branch> branch do <remoto>
• Descrição: Atualiza projeto de acordo com a branch do remoto.

stash

• Estrutura: git stash <comando>
  • <comando> comandos relacionados ao stash
    • git stash save salva modificações
    • git stash save "mensagem de descrição" salva modificações com descrição
    • git stash list lista stashes
    • git stash show exibe arquivos modificados do ultimo stash
    • git stash show -p exibe diffs do ultimo stash
    • git stash clear limpa área de stash
    • git stash apply aplica ultimo stash
    • git stash pop aplica ultimo stash e o apaga
  • <branch> branch do <remoto>
• Descrição: Salva modificações sem commitá-las.