Como criar um novo branch com as alterações atuais de código em git

Neste artigo você vai aprender a como criar um novo branch com as alterações atuais em git, com apenas dois comandos!

Fala programador(a), beleza? Bora aprender mais sobre branches em git!

As vezes acontece de você estar começando uma nova tarefa, porém no branch antigo

Então você precisa mudar de branch, mas com o código já feito, pois pode ser muita coisa, como realizar esta ação?

Se você não commitou nada ainda é simples, basta utilizar o comando:

git checkout -b <name>

Você vai criar um novo branch com as alterações já feitas 🙂

Se já houve algum commit o mais indicado é criar o novo branch a partir do atual, desta maneira os dois ficarão iguais

Então você já tem o seu ponto de trabalho criado

Agora volte ao branch original e utilize o comando git reset, com muito cuidado que é um comando destrutivo

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

Exemplo:

git reset --soft HEAD~2

No comando acima, voltamos dois commits

HEAD significa o ponto atual, e o número depois é a quantidade de commits desfeitos

Quer aprender mais sobre git? Veja este curso gratuito:

Conclusão

No artigo de hoje você aprendeu a como criar um novo branch com as alterações atuais em git

Utilizamos o comando git checkout para alterações não commitadas

Se você commitou algo, será preciso utilizar o git reset para voltar as versões no branch que não era pra ter sido alterado

Confira nossos cursos gratuitos no Youtube, com vídeos todos os dias!Se inscreva e ative o sininho para receber as notificações e aprender mais ainda sobre desenvolvimento web!

Veja também nosso catálogo de cursos na Udemy, todos com exercícios e projetos práticos, nas mais diversas tecnologias. O link acima contém um cupom de desconto para os cursos!

Por que as alterações vão junto pro novo branch?

Isso pega muita gente de surpresa, então vale explicar o porquê antes do como

Enquanto tu não commita nada, o teu código alterado não pertence a branch nenhum

Ele fica solto ali na tua área de trabalho, esperando alguém dizer onde ele vai morar

O branch, por sua vez, é só um marcador apontando pra um ponto do histórico

Se você conhece atalho de pasta no Windows, é bem parecido: o atalho aponta pro lugar, mas não carrega o arquivo dentro dele

Por isso o checkout com -b cria o marcador novo e te leva junto com tudo que estava na mesa

Nada foi copiado, nada foi movido, só mudou o lugar pra onde o próximo commit vai apontar

Faz sentido, né? 😀

E se o Git não deixar trocar de branch?

Tome cuidado, porque nem sempre a troca é lisa

Quando o arquivo que tu alterou também está diferente no outro branch, o Git trava a troca pra não passar por cima do teu trabalho

E aí ele reclama em vez de obedecer, o que é ótimo (já me ferrei por ignorar aviso de ferramenta antes)

Nesse caso você tem duas saídas

A primeira é fechar o que fez num commit no branch atual, mesmo que seja um commit temporário, e trocar depois

A segunda é guardar essas alterações na área temporária do próprio Git, trocar de branch e trazer elas de volta em seguida

As duas resolvem, a diferença é só o quanto tu quer deixar registrado no histórico

O git reset apaga o meu código?

Boa pergunta, e a resposta é: depende do que tu pede pra ele

No exemplo acima, com o –soft, o Git só recua o marcador do branch

Os commits saem do caminho, mas os arquivos continuam exatamente como estavam

É como arrancar as últimas páginas do caderno e seguir com o texto na mão, pronto pra escrever de novo

Porém o reset tem outras variações, e tem variação que joga as alterações fora de verdade

Então nunca copie um reset de qualquer lugar sem saber qual variação está ali no meio

Antes de rodar, confirme três coisas

Você está mesmo no branch original?

O trabalho que interessa já está salvo no branch novo?

O número de commits que tu quer desfazer é esse mesmo?

Se as três respostas forem sim, pode mandar

E se esse branch já foi enviado pro remoto?

Aqui muda o jogo, se liga nisso

Desfazer commit em branch que só existe na tua máquina é de boa, ninguém sente

Agora, se esses commits já subiram e tem outra pessoa trabalhando em cima deles, tu está reescrevendo um histórico que não é mais só teu

O resultado costuma ser aquele mal-estar no time, com gente perdendo commit sem entender o motivo

Nesses casos o caminho seguro é combinar com quem usa o branch antes de mexer, ou desfazer o efeito daquele commit num commit novo em vez de apagar o passado

Regra simples: histórico local tu ajusta à vontade, histórico compartilhado tu negocia

Por que isso acontece tanto hoje em dia?

Vale um parêntese, porque o cenário mudou bastante desde que esse post nasceu

Antes tu escrevia linha por linha e percebia rápido que estava no branch errado

Hoje é normal soltar uma tarefa pra IA, ir tomar um café e voltar com um monte de arquivo alterado de uma vez

Aí o estrago no branch errado é bem maior, porque tu só nota quando o trabalho já está todo feito

A boa notícia é que a saída continua sendo essa mesma daqui de cima, não tem fórmula mágica nenhuma

O hábito que salva é simples: conferir em qual branch tu está ANTES de soltar a tarefa

E, se esquecer, você já sabe o caminho de volta 😉