Seu primeiro repositório: git init, add e commit

1. Criando um repositório com git init

Um repositório Git é essencialmente um diretório que contém todo o histórico de versões do seu projeto. Quando você inicializa um repositório, o Git cria uma pasta oculta chamada .git dentro do diretório do projeto. Essa pasta armazena todos os metadados e objetos necessários para o versionamento.

Para criar seu primeiro repositório, navegue até o diretório desejado e execute:

$ cd ~/projetos/meu-primeiro-repo
$ git init
Initialized empty Git repository in /home/usuario/projetos/meu-primeiro-repo/.git/

Você pode verificar que a pasta .git foi criada com:

$ ls -la .git
total 28
drwxr-xr-x 7 usuario usuario 4096 mar 10 10:00 .
drwxr-xr-x 3 usuario usuario 4096 mar 10 10:00 ..
drwxr-xr-x 2 usuario usuario 4096 mar 10 10:00 branches
-rw-r--r-- 1 usuario usuario   92 mar 10 10:00 config
-rw-r--r-- 1 usuario usuario   73 mar 10 10:00 description
-rw-r--r-- 1 usuario usuario   23 mar 10 10:00 HEAD
drwxr-xr-x 2 usuario usuario 4096 mar 10 10:00 hooks
drwxr-xr-x 2 usuario usuario 4096 mar 10 10:00 info
drwxr-xr-x 4 usuario usuario 4096 mar 10 10:00 objects
drwxr-xr-x 4 usuario usuario 4096 mar 10 10:00 refs

Agora seu projeto está sob controle de versão, mas ainda não há nenhum arquivo sendo rastreado.

2. Adicionando arquivos ao projeto

Vamos criar alguns arquivos no diretório de trabalho:

$ echo "# Meu Primeiro Projeto" > README.md
$ echo "console.log('Olá, Git!');" > app.js

Para verificar o estado atual do repositório, use git status:

$ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md
        app.js

nothing added to commit but untracked files present (use "git add" to track)

Arquivos "untracked" são aqueles que o Git ainda não está monitorando. Eles existem no diretório de trabalho, mas não fazem parte do histórico do repositório. Para que o Git comece a rastreá-los, precisamos movê-los para o staging area.

3. O comando git add e o staging area

O staging area (ou área de preparação) é um espaço intermediário onde você organiza as alterações que deseja incluir no próximo commit. Para adicionar um arquivo específico:

$ git add README.md

Verifique o status novamente:

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   README.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        app.js

Agora README.md aparece em "Changes to be committed" — está no staging area. app.js continua untracked.

Para adicionar múltiplos arquivos de uma vez, você pode usar:

$ git add app.js

Ou adicionar todos os arquivos do diretório atual com:

$ git add .

Outra opção é git add -A, que adiciona todas as alterações em todo o repositório (incluindo arquivos deletados). Ambos os comandos são equivalentes na maioria dos casos.

Após adicionar ambos os arquivos:

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   README.md
        new file:   app.js

4. Realizando o primeiro commit com git commit

Com os arquivos no staging area, podemos criar um snapshot do projeto com git commit:

$ git commit -m "Commit inicial: adiciona README e app.js"
[master (root-commit) a1b2c3d] Commit inicial: adiciona README e app.js
 2 files changed, 2 insertions(+)
 create mode 100644 README.md
 create mode 100644 app.js

A flag -m permite escrever a mensagem de commit diretamente na linha de comando. Mensagens claras e descritivas são fundamentais para entender o histórico do projeto. Um bom commit deve responder "por que esta alteração foi feita?".

Internamente, o Git criou um snapshot do staging area. Cada commit recebe um hash único (como a1b2c3d) que identifica aquele ponto na história.

5. Visualizando o histórico de commits

Para ver o histórico de commits realizados:

$ git log
commit a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 (HEAD -> master)
Author: Seu Nome <seu@email.com>
Date:   Mon Mar 10 10:05:00 2025 -0300

    Commit inicial: adiciona README e app.js

Para uma visualização mais compacta:

$ git log --oneline
a1b2c3d (HEAD -> master) Commit inicial: adiciona README e app.js

O --oneline exibe apenas o hash abreviado e a mensagem do commit, facilitando a navegação quando há muitos commits.

6. Ciclo básico de trabalho: editar, adicionar, commitar

O fluxo de trabalho fundamental no Git é um ciclo repetitivo:

  1. Modificar arquivos no diretório de trabalho
  2. Adicionar as alterações ao staging area
  3. Commmitar as alterações

Vamos simular uma alteração:

$ echo "## Descrição" >> README.md
$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")

Note que README.md agora aparece como "modified" (arquivo tracked que foi alterado). Precisamos adicioná-lo ao staging e commitar:

$ git add README.md
$ git commit -m "Adiciona seção de descrição ao README"

A diferença entre arquivos tracked e untracked:
- Tracked: arquivos que o Git monitora (já foram commitados ou estão no staging)
- Untracked: arquivos novos que nunca foram adicionados ao Git

Boas práticas recomendam commits pequenos e atômicos — cada commit deve representar uma única mudança lógica. Isso facilita revisões, reversões e entendimento do histórico.

7. Ignorando arquivos com .gitignore

Nem todos os arquivos devem ser versionados. Arquivos temporários, logs, dependências ou arquivos de configuração local devem ser ignorados. Para isso, criamos um arquivo .gitignore:

$ echo "*.log" > .gitignore
$ echo "node_modules/" >> .gitignore
$ echo ".env" >> .gitignore

Adicione e commite o .gitignore:

$ git add .gitignore
$ git commit -m "Adiciona .gitignore para ignorar logs, node_modules e .env"

Agora, se criarmos um arquivo de log:

$ echo "erro crítico" > debug.log
$ git status
On branch master
nothing to commit, working tree clean

O debug.log não aparece no status porque corresponde ao padrão *.log no .gitignore.

Padrões comuns de .gitignore:
- *.log — ignora todos os arquivos com extensão .log
- node_modules/ — ignora a pasta de dependências do Node.js
- .env — ignora arquivos de configuração de ambiente
- build/ — ignora a pasta de artefatos de compilação

Você pode verificar quais regras estão sendo aplicadas com:

$ git check-ignore debug.log
debug.log

O .gitignore deve ser commitado no repositório para que todos os colaboradores do projeto ignorem os mesmos arquivos.

Com estes comandos fundamentais — git init, git add e git commit — você já pode começar a versionar seus projetos. Lembre-se de commitar com frequência, escrever mensagens claras e usar .gitignore para manter seu repositório limpo.

Referências