Ir para o conteúdo
  • Empresa
    • SOBRE NÓS
    • TRABALHE CONOSCO
  • Soluções
    CONSULTORIA CLOUD
    • GET STARTED
    • DESIGN
    • IMPLANTAÇÃO
    MIGRAÇÃO
    SQUAD AS A SERVICE
    WELL ARCHITECTED
    SEGURANÇA E COMPLIANCE
    • MSSP
    • SECAAS
    • OFFENSIVE ACTIONS
    • SRT
    • REVENDA
    BIG DATA & MACHINE LEARNING
    • Analytics
    • AI/ML
    SERVIÇOS GERENCIADOS
    • MONITORAÇÃO 24x7
    • DAREDE MSP
    • GERENCIAMENTO DEVOPS
    • GERENCIAMENTO DEVSECOPS
    • GERENCIAMENTO FINOPS
    • GERENCIAMENTO DE BANCO DE DADOS
    • GERENCIAMENTO DE PABX IP
    • LICENCIAMENTO DE SOFTWARE
    COMPETÊNCIAS AWS
    • AWS CLOUD FRONT
    • AWS AURORA
    • AMAZON RDS
    • DEVOPS
    • MICROSOFT WORKLOADS
    • MIGRATION
    • PUBLIC SECTOR
    • PUBLIC SECTOR NPO
    • PUBLIC SECTOR EDUCATION
    • WELL ARCHITECTED
    • VMWARE CLOUD ON AWS
    • API GATEWAY
    • LAMBDA
    • NETWORKING ON AWS
    • FINANCIAL SERVICES
  • Cases
  • Blog
Darede Portugal
  • Fale Conosco
  • Canal Compliance
  • Seja Parceiro Autorizado
Continuando a série de artigos sobre Git, nosso #cloudspecialist Thiago Marques traz agora um artigo que aborda a diferença entre merge e rebase! Confere aí!

10/02/2023

Por Thiago Marques

O pai tá on!!

Em nosso último post falamos sobre o poder que o GIT tem na utilização de ramificações (branches), contudo isso gera uma grandedúvida: Beleza, mas como faço para juntar a minha ramificação conteúdo, com a ramificação principal (master/main)?

Nesse post iremos falar sobre o merge que é justamente poder juntar branches, e a diferença entre um merge e um rebase.

Git merge

O comando git merge é a forma que o git possui de unificar branches, ou seja, com ele conseguimos do branch atual puxar o histórico do branch alvo, gerando um commit de unificação.

Isso ocorre apenas no branch onde vamos unificar, para o branch ‘alvo’, vai ser como as alterações não tivessem ocorrido.

Na prática, o git vai avaliar os dois históricos dos branches, e tentar mesclar automaticamente os históricos. o que as vezes não dá certo e ocorrem os famosos conflitos, onde é necessário intervenção do usuário para conclusão.

Para evitar os conflitos, o ideal é sempre seguir um bom procedimento de passos, no qual recomendo o sugerido pela Atlassian, cito-o:

1.      Entre no branch que vai receber o merge, ou seja, aquele que desejamos manter depois da unificação;

2.      Atualize os commits mais recentes nas duas branches, o que pode ser feito com o comando:

git fetch –all

3.      Execute o merge com o comando:

git merge <branch_alvo>

 

Para ficar mais claro, vamos imaginar o seguinte cenário: Temos a branch principal (main), que é a responsável pelas matérias do blog. Então criamos a branch conteudo, que irá focar em todo tipo de conteúdo projeto em si, e por fim, para segmentar ainda mais criamos uma ramificação dentro da branch artigos que vai focar apenas em artigos científicos (que é exatamente o que fizemos com o exemplo do visualizing no último post).

Agora precisamos unificar todos os branches no principal para assim ter os conteúdos para postar no blog, com isso temos os seguintes passos:

1.      Criar o branch conteudo e executar dois commits;

2.      Executar dois commits na branch master;

3.      Criar o branch artigos como ‘filha’ da branch conteúdos, e executar dois commits;

4.      Criar o merge da branch conteúdo com a artigos;

5.      Criar o merge da branch artigos com a principal;

Obs.: Para o merge sempre conectamos na branch que vai RECEBER o merge, e PUXAMOS o histórico da branch que queremos.

Colocando a mão na massa temos:

Git rebase

O rebase é uma outra forma de se juntar branches, contudo com algumas características mais ‘radicais’. Apesar de manter o histórico de forma linear, ele pega os logs do branch ativo e coloca na frente do branch alvo, além de não gerar o ‘commit de merge’.

Note que mesmo isso gerando um histórico linear, gera um problema, pois ele mexe com a estrutura dos branches, reescrevendo todo o histórico dos commits. E justamente por características assim é que existe uma regra de ouro que recomenda que não seja feito rebase em branches públicos, uma vez que a possibilidade de ‘dar ruim’ é grande.

O comando que usamos para fazer o rebase é:

  • #logado na branch principal
  • git rebase <branch_secundária>

Ressaltando mais uma vez: o rebase tem um grande poder, mas como diria o Tio Bem: “com grandes poderes vem grandes responsabilidades”, então utilize ele em situações especifica.

That’s all folks! Be Happy!!!

foto-thiago-marques
Thiago Marques Technical Account Manager

Technical Account Manager da Darede, formado em Rede de Computadores e pós-graduado em Segurança da Informação. Possui ampla experiência em Datacenters e Service Providers, além de ser um entusiasta em DevOps e mercado financeiro.

OUTRAS PUBLICAÇÕES

O que é o Amazon Cognito?

Entenda de forma prática e simplificada como o Amazon Cognito funciona e pode auxiliar seu ambiente em cloud! Confere aí!

Conectando On-Premises na AWS via Direct Connect

Confira o artigo técnico escrito pelos colaboradores Adassa Lima e Matheus Arantes sobre Conectando On-Premises na AWS via Direct Connect. Confere lá!

Novidades da AWS – DevOps: 20 de maio a 20 junho

Os #cloudspecialists da Darede reuniram as principais novidades de DevOps da AWS! Confira quais são elas e como elas podem te ajudar!

O que é Infrastructure as Code (IaC)?

A Infrastructure as Code é um modo de automatizar o provisionamento da infraestrutura de TI e aliada com a cultura DevOps pode ser de grande ajuda para as empresas. Confira o artigo do blog sobre esse conceito.

Os Desafios de um Setor de Qualidade em empresas de Cloud.

Veja alguns dos principais desafios enfrentados pelos profissionais da qualidade em uma empresa de nuvem e como eles podem ser superados.

Darede conquista prêmio de Collaboration Partner of the Year – LATAM

A AWS premiou os parceiros ao redor do mundo que mais se destacaram no ano.

« Anterior Página1 Página2 Página3 Página4 Página5 Página6 Página7 Página8 Página9 Página10 Próxima »
  • E-books
  • Blog
Conecte-se conosco
Mais
  • Fale Conosco
  • Canal Compliance
  • Seja Parceiro Autorizado
  • Governança Corporativa

Escritórios

  • Alameda Araguaia, 2044 - Bloco 1 - CJ 210/211 06455-000 - Alphaville, Barueri São Paulo - Brasil
  • Dabi Business Park - R. Gen. Augusto Soares dos Santos, 100 - Parque Industrial Lagoinha Ribeirão Preto, São Paulo, 14095
  • Avenida Bombeiros Voluntários de Algés 44 Lisbon , Algés, 1495 Oeiras
  • +55 11 3900-1010 | 3995-6919
newsletter
  • Política de Privacidade e Cookies
  • Perguntas Frequentes
© Copyright 2025 Darede à nuvem
Todos os direitos reservados | By Damidia Marketing & Conteúdo
Rolar para cima

Nós usamos cookies para garantir e oferecer a melhor experiência de navegação em nosso site! Mais informações

ACEITAR & FECHAR
RECUSAR