Rotina diária de trabalho com Git

Neste artigo, vamos percorrer o fluxo básico que se repete todos os dias: obter uma cópia do projeto, salvar as alterações (commit), enviá-las ao GitHub (push) e configurar o .gitignore para ignorar arquivos desnecessários. É o mesmo fluxo que o Claude Code executa em seu lugar ao trabalhar com um repositório, por isso vale ainda mais a pena entendê-lo.

Os exemplos e as capturas de tela mostram a IDE da JetBrains; os nomes e a localização das ações podem variar conforme a versão instalada. Para praticar, use um repositório separado de treinamento. Em projetos de trabalho, siga as regras do próprio projeto para branches, commits e envio de alterações.

Clonar um projeto

Com um repositório no GitHub, o próximo passo é obter uma cópia local no computador para começar a trabalhar. Esse processo se chama clonagem.

Etapa 1. Abra a IDE. Se houver algum projeto aberto, feche-o em File | Close Project. Na tela inicial (Welcome Screen), selecione Clone Repository (ou Get from VCS).

Etapa 2. Na janela que abrir, cole o URL do repositório. Essa opção é prática para clonar o repositório de outra pessoa: basta copiar o URL da página do repositório no GitHub.

Para clonar um repositório próprio, o jeito mais simples é entrar na conta do GitHub pela IDE, usando Log in to GitHub. A IDE abrirá o navegador para autenticação.

Na página aberta, clique no botão verde Authorize JetBrains. Depois disso, será possível escolher os repositórios diretamente na lista da IDE. Selecione o projeto desejado e clique em Clone.

Etapa 3. Confirme se o(a) senhor(a) confia no projeto. Para um repositório próprio e conhecido, o(a) senhor(a) pode selecionar Trust Project. Se não conhecer o projeto, examine primeiro o conteúdo e as instruções de execução: a confiança permite que a IDE execute ações do projeto.

Etapa 4. Abra o projeto. No Windows, a IDE pode sugerir exceções no antivírus para acelerar a indexação. Elas não são necessárias para estudar Git; não desative a proteção para clonar o projeto.

Salvar alterações - commit

commit é um instantâneo, um estado salvo do projeto em determinado momento. Pense nele como um ponto de salvamento em um jogo: o(a) senhor(a) sempre pode voltar a esse ponto se algo der errado. Cada commit tem um identificador único e uma mensagem que descreve as alterações.

O histórico de commits mostra uma sequência: cada novo commit parte do anterior e registra a evolução do projeto.

Etapa 1. Faça alterações. Abra o arquivo README.md e adicione uma descrição do projeto. Assim que o(a) senhor(a) começar a editar o arquivo, a IDE destacará o nome dele em azul no painel do projeto: isso indica que o arquivo foi alterado, mas as mudanças ainda não foram salvas no Git. Ao lado das linhas alteradas, a IDE mostrará uma faixa colorida: verde para linhas adicionadas e azul para linhas modificadas.

Abra a aba Commit e confira os arquivos alterados. No modo padrão da JetBrains, eles aparecem em listas de alterações (changelists); a staging area do Git precisa ser ativada à parte nas configurações. Não confunda as caixas de seleção dessa janela com o índice já preparado no terminal.

O que aparece aqui:

• Changes - arquivos já rastreados pelo Git que foram alterados (neste caso, README.md);
• Unversioned Files - arquivos novos que o Git encontra na pasta do projeto, mas ainda não rastreia.

Etapa 2. Confira o diff selecionado. Os arquivos novos em Unversioned Files ainda não são rastreados. Em geral, resultados de build, cache e configurações pessoais ficam de fora por meio do .gitignore. Configurações compartilhadas do projeto podem ser mantidas no Git: confira as regras do projeto antes de ignorar a pasta .idea/ inteira.

Etapa 3. Faça o commit. Escreva uma mensagem clara, por exemplo docs: Describe the project in README, confira o diff selecionado e clique em Commit. Se houver verificações antes do commit, aguarde o resultado. Abra o Git Log e confirme que o novo commit inclui o arquivo esperado.

Enviar alterações ao GitHub - push

Por enquanto, seus commits estão apenas no computador. Para compartilhá-los com a equipe ou guardá-los em um local confiável, envie-os ao repositório remoto no GitHub.

O push atualiza a branch remota selecionada com os seus commits. Ele não baixa o trabalho de outras pessoas nem envia arquivos sem commit.

Etapa 1. Clique em Push. O botão Push fica na barra superior principal (Main Toolbar) e tem o ícone de uma seta apontando para cima e para a direita.

Etapa 2. Confira e confirme. Uma janela será aberta com todos os commits prontos para envio. Esta é a última chance de conferir se o(a) senhor(a) está enviando exatamente o que pretendia. Clique em Push.

Quando o envio for concluído, a IDE mostrará uma notificação. Confira nela o repositório e a branch de destino: neste exercício, é origin/main. O texto da notificação varia conforme a versão da IDE.

Etapa 3. Confira o resultado no GitHub. Abra a página do repositório no GitHub pelo navegador e veja que suas alterações e arquivos estão lá.

Painel de controle do Git

A IDE tem um painel de ferramentas separado para o Git, além de ações rápidas na barra superior. É o seu centro de controle de versões. Os botões principais são:

• Commit (marca de seleção) - abre o painel para salvar as alterações;
• Push (seta para cima e para a direita) - abre a janela para enviar commits ao GitHub;
• Branches - widget para gerenciar branches (no canto superior esquerdo);
• Show Git Log - todo o histórico de commits do projeto, sua máquina do tempo particular.

Obter atualizações

Update Project busca as alterações e as integra à branch local; a IDE usa merge ou rebase conforme a configuração. Antes de atualizar, salve o trabalho que ainda não terminou e confira o método de atualização selecionado.

Antes de começar uma nova tarefa, confira o estado dos arquivos e se a branch necessária está atualizada. Se houver commits de outras pessoas, obtenha-os e integre-os conforme as regras do projeto. A atualização pode exigir a resolução de conflitos e não impede que surjam novos no futuro.

Ignorar arquivos desnecessários - .gitignore

Se o projeto gerar arquivos auxiliares ou resultados de build que o(a) senhor(a) não quer incluir por engano no repositório, adicione-os à lista de exclusão. Para isso, crie na raiz do projeto um arquivo especial chamado .gitignore.

O que costuma ser ignorado e por quê

Quase toda stack tem arquivos que não devem entrar no Git porque são específicos do seu computador ou são gerados novamente durante o build:

• pastas de build (por exemplo, build/, dist/) - resultados de compilação que podem ser recriados facilmente;
• cache do gerenciador de pacotes e dependências (por exemplo, node_modules/) - podem ocupar centenas de megabytes e são específicos do seu sistema;
• configurações pessoais da IDE, como o estado da janela de trabalho. A pasta .idea/ também pode conter configurações compartilhadas do projeto, então só a ignore por completo se essa for a regra adotada no projeto;
• arquivos do sistema operacional (.DS_Store, Thumbs.db) - lixo que o sistema cria automaticamente.

Como ignorar um arquivo manualmente:

Etapa 1. Imagine que o(a) senhor(a) criou o arquivo local notes.txt para guardar anotações de rascunho. Clique nele com o botão direito na árvore do projeto.

Etapa 2. No menu, selecione Git -> Add to .gitignore -> Add to .gitignore. Essa opção adicionará o arquivo selecionado ao .gitignore na raiz do projeto.

Se ainda não existir um arquivo .gitignore, a IDE oferecerá a opção de criá-lo. Aceite.

Etapa 3. A IDE adicionará automaticamente o nome do arquivo ao .gitignore.

Um arquivo não rastreado que corresponda à regra geralmente desaparece da lista de arquivos a adicionar; a cor na IDE varia conforme o tema. Isso não impede a adição forçada nem remove do histórico o que já foi salvo. Faça commit do próprio .gitignore se a regra precisar valer para todos.

Regras do .gitignore

O arquivo contém padrões para nomes de arquivos e pastas que o Git deve ignorar. Linhas em branco são ignoradas, e um comentário começa com o caractere #.

• * - substitui qualquer quantidade de caracteres. Por exemplo, *.log ignora todos os arquivos com a extensão .log;
• / no fim do padrão indica um diretório. Por exemplo, build/ ignora todo o conteúdo da pasta build;
• ! no início da linha inverte a regra. Por exemplo, com a regra *.log, a linha !important.log exclui esse arquivo da regra de ignorar; ele começará a ser rastreado depois de ser adicionado;
• ** entre barras corresponde a qualquer quantidade de pastas aninhadas, inclusive nenhuma. Por exemplo, logs/**/*.log encontra tanto logs/a.log quanto logs/2026/09/a.log.

Exemplo de arquivo .gitignore

# Pastas de build e cache
build/
dist/
node_modules/

# Estado pessoal da IDE (JetBrains)
.idea/workspace.xml

# Arquivos do sistema operacional
.DS_Store
Thumbs.db

Modelos prontos

Não é preciso escrever esses arquivos do zero. Existem modelos prontos, testados pela comunidade:

1. coleção de arquivos .gitignore do GitHub para várias linguagens e frameworks: https://github.com/github/gitignore;
2. gitignore.io - serviço web que gera um .gitignore para as tecnologias que o(a) senhor(a) usa (basta informar a linguagem, o sistema operacional e a IDE).

Como isso funciona com o Claude Code

O Claude Code pode executar esse mesmo fluxo diário em seu lugar. Veja o que observar:

• o Claude pode fazer o commit e o push por conta própria - confira o que entrou no commit e leia a mensagem;
• um .gitignore bem configurado ajuda a excluir o que não deve entrar, mas ainda assim confira os arquivos selecionados antes do commit;
• antes de atualizar, confira o estado da branch e o trabalho ainda não concluído; depois, confira o resultado da integração.

Artigo anterior: Introdução ao Git e ao GitHub · Próximo artigo: Branches e merge no Git