Fluxo de Trabalho no Git

Artigo atualizado em Setembro 2026: o exemplo de merge agora mostra o fluxo certo (mesclar a feature na main antes do push), incluímos como ligar o repositório local ao remoto origin e corrigimos o que o HEAD representa.

Salve salve Pythonista!

Nesse post você vai aprender o fluxo de trabalho do Git! Se ainda está conhecendo a ferramenta, vale ler antes o post sobre o Git e seus principais comandos.

Você verá:

• Como realizar a configuração inicial do Git com git config e criar um repositório com git init
• Os estados do Fluxo de Trabalho do Git: Working Directory, Staging e Repository.
• Como verificar o estado da sua branch com git status.
• Adicionar arquivos à área de Staging com git add.
• Como criar commits com git commit.
• Como criar branches com git branch.
• Como mesclar códigos de diferentes branches com git merge.
• Como atualizar o repositório remoto com git push.
• E muito mais!

Então vamos nessa!

Vá Direto ao Assunto…

• Configuração Inicial do Git
• Fluxo de trabalho no Git
• Ramificações do projeto Git
• Atualizando o servidor remoto Git

Configuração Inicial do Git

Após a instalação do git, você deve definir seu usuário e email para que esses dados sejam utilizados pelo git ao criar um commit.

Fazemos isso através dos seguintes comandos:

1
2

git config --global user.name "Seu nome"
git config --global user.email [email protected]

Após ter feito isso, vá a pasta do projeto e use o comando git init para inicializar um novo repositório:

1

git init

Está curtindo esse conteúdo?

Que tal receber 30 dias de conteúdo direto na sua Caixa de Entrada?

Sua assinatura não pôde ser validada.

Você fez sua assinatura com sucesso.

Assine as PyDicas e receba 30 dias do melhor conteúdo Python na sua Caixa de Entrada: direto e sem enrolação!

Seu nome

Seu e-mail

ASSINAR PYDICAS

Fluxo de trabalho no Git

Quando se está trabalhando localmente, o git representa seu repositório em três estados distintos.

O primeiro deles é a Working Directory que contém a versão atual dos arquivos do projeto.

O segundo é o Staging (Index), que funciona como uma área temporária que diz ao git o que irá em seu próximo commit.

Por último, temos o Repository (HEAD), o histórico de commits guardado na pasta .git do seu computador. O HEAD aponta para o último commit da branch em que você está. Tudo isso é local: o repositório remoto só recebe esses commits quando você faz git push.

O principal comando para determinar quais os estados atuais dos arquivos do projeto é:

1

git status

Para mover apenas um arquivo da Working Directory para o Staging, utilizamos:

1

git add <arquivo>

Ou, para mover todos os arquivos novos e modificados da pasta atual (inclusive subpastas):

1

git add .

Prefira git add . a git add *: o * é expandido pelo shell, ignora arquivos ocultos (como .gitignore) e não registra arquivos que você apagou.

E para gravar no Repository tudo o que está no Staging, criando um commit:

1

git commit -m "Mensagem do commit"

Estou construindo o Ebookr.ai, uma plataforma onde você cria ebooks profissionais com IA sobre qualquer assunto - do zero ao PDF pronto, com capas e infográficos gerados automaticamente. Dá uma olhada!

Ramificações do projeto Git

Utilizamos as chamadas Branches para desenvolver código isoladamente.

Isto é, ao se trabalhar em uma branch, podemos testar e experimentar à vontade, sem interferir no trabalho de outros, bastando retornar à branch original para se ter a versão anterior do código.

Todo repositório novo começa com uma única branch, a branch “padrão”. No GitHub e no GitLab ela se chama main (antigamente master). Já o git init ainda pode criar master, dependendo da versão e da configuração do seu Git. Para padronizar em main, rode uma vez:

1

git config --global init.defaultBranch main

O comando para se criar uma nova branch é o:

1

git branch <nome da branch>

Você pode mudar de branch utilizando o comando:

1

git checkout <nome da branch>

Desde o Git 2.23 também existe o git switch <nome da branch>, feito só para trocar de branch (e git switch -c <nome> cria e já muda para a nova branch).

Visualmente, esse é o funcionamento de uma branch - uma ramificação no código:

Ramificar seu código em branches só vale a pena quando há um projeto Python de verdade evoluindo por trás - é esse tipo de projeto que você constrói na Jornada Python, do básico ao Django:

Domine Python: A Linguagem da Inteligência Artificial, do Desenvolvimento Web e das Carreiras do Futuro.

A mais completa formação para você se tornar um especialista em Python, pronto para construir desde aplicações web robustas com Django até projetos de Inteligência Artificial e Ciência de Dados .

Quero conhecer!

Nota 4,9 de 5 na Hotmart O curso de Python mais bem avaliado da Hotmart!

Atualizando o servidor remoto Git

Ao finalizar o desenvolvimento de uma nova funcionalidade, mesclamos os códigos da branch que foi criada com a ramificação principal do projeto (main ou master).

Fazemos isso com o comando merge.

Esse comando pega as alterações de uma branch e as aplica à outra branch:

1

git merge <branch para mesclar>

O merge sempre traz as alterações da branch informada para a branch em que você está. Por isso, para levar a funcionalidade para a main, primeiro mudamos para a main e depois mesclamos a branch da funcionalidade.

Por exemplo, se terminamos o trabalho na branch adiciona-botao-login e queremos levá-lo para a main:

1
2

git checkout main
git merge adiciona-botao-login

Desta forma, as alterações da branch adiciona-botao-login são mescladas na branch atual, a main.

O caminho inverso também existe: estando na adiciona-botao-login, um git merge main traz para a sua branch o que outras pessoas já integraram na main. É útil para manter a branch em dia enquanto você desenvolve, mas não publica sua funcionalidade na main.

Feito o merge, podemos atualizar o servidor remoto com o comando git push:

1

git push {nome servidor remoto} {branch}

Por padrão o servidor remoto se chama origin: é o nome que o git clone dá ao repositório de onde você clonou.

Se você criou o repositório com git init, ainda não existe nenhum remoto. Nesse caso, crie o repositório vazio no GitHub (ou GitLab) e ligue os dois:

1

git remote add origin <url do repositório remoto>

Portanto, para enviar a main atualizada depois do merge podemos executar o comando desta forma:

1

git push origin main

No primeiro envio de uma branch, use git push -u origin <branch>: o -u liga a branch local à remota, e nos próximos envios basta digitar git push.

Se o seu time trabalha com pull requests, o fluxo muda um pouco: em vez de mesclar localmente, você envia a própria branch (git push origin adiciona-botao-login) e o merge na main acontece pelo GitHub, depois da revisão.

Conclusão

Nesse post você aprendeu como utilizar os principais comandos do dia a dia de trabalho com o Git!

Saber utilizar o Git é crucial para sua carreira de Pythonista de sucesso! Uma boa forma de praticar é versionar desde o primeiro commit o seu primeiro projeto Django em 15 minutos.

Se ficou com alguma dúvida, fique à vontade para deixar um comentário no box aqui embaixo! Será um prazer te responder!

Git fica mais natural quando você tem projetos de verdade para versionar. Para construir esses projetos, do básico ao Django, conheça a Jornada Python, nosso curso de Python completo.

Por Vinícius Ramos em 17/04/2022

Engenheiro de Computação pela UnB com especialização em Inteligência Artificial. Sr. Software Engineer com 10+ anos de experiência desenvolvendo sistemas críticos em Python e Django. Atuei no Banco do Brasil liderando equipes para monitoramento de mainframe, trabalhei como desenvolvedor sênior em projetos forenses para a Polícia Federal, e atualmente sou engenheiro de software na Labcorp (Estados Unidos), desenvolvendo soluções escaláveis para testes genéticos. Fundador da Python Academy, compartilhando conhecimento técnico com a comunidade brasileira desde 2018.

Bora se conectar no LinkedIn! vinicius-aramos

Minhas redes:

• 
• 
•