Executando verificação de segurança...
1

Git: Guia Rápido de Nomenclaturas e Principas Comandos

Hoje em dia é primordial a pessoa desenvolvedora conhecer sobre e realizar o versionamento de código implementado.
E para isso temos o Git, uma excelente ferramenta e amplamente difundida no mercado, que é tido como padrão para esse gerenciamento de projeto.
Através dele podemos estruturar todo versionamento do nosso código, controlar alterações e organizar o fluxo de trabalho de codificação em um projeto, seja integrando uma equipe ou solo.
Para uma melhor compreensão, trago nesse artigo um guia rápido para te ajudar a entender e praticar determinados comandos mais utilizados no dia-a-dia.

Nomenclaturas

  • Repositório - é o armazenamento digital centralizado de um projeto, onde fica armazenado o código-fonte de uma aplicação, estruturado por arquivos e pastas, popularmente chamado também por "repo".
  • Git - nome do serviço de controle de versões. Mas também é o nome para qual damos ao repositório local.
  • GitHub - plataforma de hospedagem de repositórios remotos que utiliza Git para manuseio dos repositórios.
  • Stage - ambiente de armazenamento temporário para efetuar os comandos de envio de arquivos ou commit. Área de preparação.
  • Branch - é todo ramo do repositório, a grosso modo, o ramo principal costumamos chamar apenas de main e de branch os ramos abaixo do main, pode ser utilizado para um controle de modificações nos arquivos principais, onde suas modificações em branchs auxiliares não comprometem o master e poder fazer uma mesclagem mais controlada.
  • Main - é o ramo principal, onde está a versão principal do "sistema". Anteriormente popularizado como "master", de um certo tempo pra cá, essa nomenclatura vem sendo deixada de lado, hoje é comum o ramo principal ser chamado de "main".
  • Commit - é um pacote de alterações feitas no repositório. Cada commit possui arquivos alterados, autor e uma mensagem de resumo. É a ferramenta responsável por gravar o estado atual dos arquivos. Caso o arquivo não tenha sido alterado comparado ao último registro de estado dele o sistema o ignora. Caso o arquivo tenha alguma alteração o sistema permite a aquisição de um novo registro desse documento.
  • Pull Request - é uma solicitação para incorporar modificações no código de uma branch a outra. O "PR" pode ser analisado por outras pessoas integrantes do repositório, podendo sugerir alterações, realizar comentários, aprovar ou recusar, através de revisões (reviews, code reviews). Nele podemos observar possíveis conflitos na versão do código e resolvê-los. Os clientes Git em sua UI geralmente expõem as alterações feitas, o código atual para uma melhor visualização e análise pontual dessas alterações, evidenciando também os possíveis conflitos.
  • Merge - num bom fluxo de trabalho com boas práticas, a mesclagem é feita após o PR atingir métricas estabelecidas pelo time, levando em conta principalmente ausência de conflitos e aprovações. Então merge é a mescla de alterações do código provenientes de uma outra branch para a branch de destino.
  • Branch de trabalho (diretório de trabalho) - é a branch que está em uso no momento, local onde estão sendo feitas as alterações.

Detalhes da sintaxe do comando Git

  • Abreviação de opções de comandos - as opções de comandos podem ser escritas com seu nome completo ou pelo seu alias, geralmente são representados por apenas a letra sigla correspondente ao comando desejado, exemplo:
    • -all é -a
    • -delete é -d
    • -copy é -c
    • -force é -f
  • Opções nos comandos com letra maiúscula - Pegando o exemplo do comando -delete com -d e -D, a opção retratada pela letra maiúscula carrega por default a instrução --force (ou -f), ou seja, força para que o comando seja executado deixando de lado possíveis problemas ou alertas. -D seria uma opção menos verbosa para o comando -delete --force ou -d -f

Principais Comandos

  • git add é um comando usado para adicionar um arquivo que está no diretório de trabalho à área de preparação.
    • git add . ou git add --all adiciona todos os arquivos novos, modificados e removidos. Mas pode haver diferença no resultado em relação a branch de trabalho...
      • git add . será adicionado ao stage somente os arquivos a partir do diretório que você está, e os subdiretórios deste.
      • git add --all adiciona ao stage arquivos desde a raiz do repositório passando por todos os subdiretórios, e aqui está a diferença, não importa se você está na raiz ou no subdiretório.
    • git add nome-do-arquivo adiciona o arquivo selecionado
  • git branch comando utilizado para verificação em qual branch estão sendo feitas as modificações no momento, verifica a branch de trabalho
    • git branch nome-da-branch usa-se para criar uma nova branch baseada na brach que está em uso, caso a branch já exista, o espaço de trabalho é alterado para essa branch informada
    • git branch -a lista as branchs existentes no remoto
    • git branch -d nome-da-branch comando para apagar a branch local, mas somente se já tiver feito merge ou enviado as alterações para o repositório remoto
    • git branch -D nome-da-branch apaga a branch local, comando forçado, ignora o estado da branch
    • git branch -m nome-atual-da-branch novo-nome-da-branch para renomear determinada branch
  • git checkout é usado para trocar de branch e também verificar em qual branch está trabalhando no momento
    • git checkout -b nome-da-branch para criar uma nova branch a partir da branch de trabalho no momento
    • git checkout HEAD~X para checar a versão dos arquivos no commit, sendo X o número referente ao commit desejado, o último commit feito é o número 1, ou seja, vai do mais recente ao mais velho, iniciando em 1
  • git cherry-pick 0a30665 é utilizado para puxar determinado commit de uma outra branch dentro do seu repositório para a branch de trabalho, sendo nesse exemplo 0a30665 o ID do commit desejado
    • git cherry-pick 0a30665..45db035 para trazer uma sequência de commits, assim você ignora o primeiro 0a30665 e traz todo o restante até o último ID passado, aqui sendo o 45db035
    • git cherry-pick 0a30665^..45db035 assim para trazer a sequência de commits incluindo o primeiro
    • Observar que o commit na posição 1 “0a30665” precisa estar cronologicamente antes do commit da posição 2 “45db035”, ou seja, ser mais velho na timeline da branch
  • git clone copia o repositório do GitHub para o git local
  • git commit é um comando usado para adicionar todos os arquivos que estão preparados (em staging) no repositório local
    • git commit -m "Texto do Commit" para criar um commit
  • git config exibe lista de opções para configurações do git em seu ambiente local
    • Opções -global e -system
      • --global terá abrangência restrito ao seu usuário da máquina, arquivo ~/.gitconfig ou ~/.config/git/config
      • -system configuração será aplicada em todos os usuários da máquina e todos repositórios, arquivo /etc/gitconfig
      • Se nenhuma opção de ambiente for passada, será aplicada somente no repositório que estiver em uso, arquivo .git/config
    • git config --list listar configurações existentes
    • git config --global color.ui true exibir cores diferentes nos comandos git de maneira global
  • git diff exibe todas as diferenças entre a cópia local e o índice sincronizado
    • git diff --cached exibe todas as diferenças entre o índice sincronizado e o último commit
    • git diff HEAD usado tanto para mostrar as diferenças entre arquivos staged e not staged, também mostra as alterações de arquivos adicionados com git add
  • git fetch é um comando usado para obter arquivos do repositório remoto para o repositório local, mas não para o diretório de trabalho. Observar qual branch é o espaço de trabalho atual
  • git init usado para inicializar o repositório.
  • git log para exibir os commits realizados na branch, exibidos em ordem cronológica inversa, do mais recente ao mais velho. Retornando identificação do commit (em hash), nome e email do autor, data de inserção e a mensagem do commit.
    • git log --all para exibir os logs de todas as branchs
    • git log --oneline exibe os log da branch de uma forma mais resumida, usando apenas uma linha
    • git log --p exibe o registro de log com informações detalhadas
    • git log --p nome-do-arquivo exibe o registro de log com informações detalhadas do arquivo escolhido
  • git merge é um comando usado para obter os arquivos do repositório local no diretório de trabalho. É utilizado para mesclar as versões dos arquivos em diferentes branchs
  • git pull é usado para obter arquivos do repositório remoto diretamente no diretório de trabalho. É equivalente a um git fetch seguido de um git merge.
  • git push é um comando usado para adicionar todos os arquivos confirmados no repositório local ao repositório remoto. Portanto, no repositório remoto, todos os arquivos e alterações serão visíveis para qualquer pessoa com acesso ao repositório remoto.
    • git push origin main enviar estas alterações ao seu repositório remoto
  • git revert 0a30665 para reverter os arquivos na versão do commit específico, sendo nesse exemplo 0a30665 o ID do commit desejado, é criado um novo commit com essa reversão
  • git remote -v verificar status do git remoto
    • git remote add origin URL_DO_REPOSITÓRIO adicionar ao repositório local o repositório criado no GitHub (git remoto)
  • git reset HEAD~X retornar estado através da ordem de commits, do mais recente ao mais velho (X é o número referente ao commit)
  • git status confere o status e reporta se existe algum arquivo para fazer um commit, se o repositório está com o atual estado do diretório de trabalho e não existem modificações a serem gravadas e se existe algum arquivo em staging
Carregando publicação patrocinada...
2

Complementando, seguem outros posts que já tivemos sobre o assunto:


E só pra ser chato (eu sou mesmo, fazer o que): embora muitos pensem na analogia do "main é o principal, e branch é o que está abaixo", vale lembrar que um branch do Git é simplesmente um ponteiro para um commit. De certa forma, está explicado aqui e aqui (e estes posts têm outros links para mais detalhes, sugiro ler tudo para um entendimento completo). Inclusive, o segundo link explica bem como os commits são gravados internamente.

Entendo que a analogia simplificada pode facilitar o entendimento, principalmente para quem está começando, mas enfim, eu já disse que sou chato, né? :-)


"Caso o arquivo não tenha sido alterado comparado ao último registro de estado dele o sistema o ignora".

Na verdade, neste caso o commit vai simplesmente apontar para o mesmo objeto blob para o qual o commit anterior estava apontando. O "último registro de estado" não é ignorado, ele também faz parte do commit (o link já indicado explica em detalhes). O que muda é se o novo commit vai apontar para o arquivo modificado, ou para o mesmo arquivo que o commit anterior apontava, mas o arquivo nunca é ignorado (ele sempre "faz parte" do commit).


Sobre a questão do "main vs master", alguns serviços (como o GitHub e o GitLab) decidiram mudar para main quando vc cria um projeto novo pela interface deles. Mas se vc usar somente o Git na linha de comando (ou seja, git init em uma pasta local) - pelo menos até a versão atual, que é a 2.42.0 - o branch inicial padrão ainda é o master (embora seja possível alterá-lo para qualquer nome que vc quiser). Aliás, ainda existem muitos projetos, especialmente os antigos, que não mudaram a nomenclatura.

De qualquer forma, vale lembrar que esses nomes são apenas convenções, incluindo a decisão de considerá-los a "versão principal do sistema". Pelo que vejo, essa convenção sempre é adotada, mas nada impede que vc trabalhe de forma diferente, se tiver uma boa justificativa.


Por fim, vale lembrar que desde a versão 2.23.0 do Git (de 2019), existem os comandos switch e restore. Tem uma explicação mais detalhada aqui, mas pra resumir, o primeiro trabalha com branches e o segundo com arquivos, e servem como substitutos para checkout.

Por exemplo, para mudar de branch, use git switch nome_branch (ou git switch -c nome_branch para criar o branch e mudar para ele). Já o git restore arquivo restaura o arquivo para o estado em que estava no último commit (ou seja, é similar a git checkout arquivo). Pois é, checkout pode trabalhar com branches ou arquivos, dependendo das opções passadas na linha de comando (e essa confusão foi o motivador para criarem switch e restore).