Complementando, seguem outros posts que já tivemos sobre o assunto:
- https://www.tabnews.com.br/yurikerber/guia-basico-sobre-git
- https://www.tabnews.com.br/Ernane/guia-rapido-e-pratico-dos-principais-comandos-git
- https://www.tabnews.com.br/Yagasaki/introducao-ao-git-e-github-para-iniciantes
- https://www.tabnews.com.br/mpoda/git-e-github-guia-basico-e-boas-praticas-de-pull-request
- https://www.tabnews.com.br/edsoncosta/git-mini-manual-lista-de-comandos-basicos
- https://www.tabnews.com.br/carlos/guia-completo-instalacao-configuracao-do-git-e-criacao-do-primeiro-repositorio-no-github-windows-e-linux
- https://www.tabnews.com.br/GabrielSozinho/githowto-um-guia-para-aprender-git-do-zero
- https://www.tabnews.com.br/JeanJr/guia-de-bolso-para-commits-semanticos
- https://www.tabnews.com.br/danilocarsan/este-e-um-guia-guia-de-versionamento-nomenclatura-git-que-usso-e-tenho-melhorado-o-que-eu-pederia-melhorar-aberto-a-sugestao-e-discussao
- https://www.tabnews.com.br/cauesooouza/quer-aprender-git-de-uma-forma-interativa
- https://www.tabnews.com.br/Vicrrs/introducao-ao-git
- https://www.tabnews.com.br/jess/primeiros-passos-com-o-git-e-o-github
- https://www.tabnews.com.br/Kayke/git
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
).