- Популярные видео
- Авто
- Видео-блоги
- ДТП, аварии
- Для маленьких
- Еда, напитки
- Животные
- Закон и право
- Знаменитости
- Игры
- Искусство
- Комедии
- Красота, мода
- Кулинария, рецепты
- Люди
- Мото
- Музыка
- Мультфильмы
- Наука, технологии
- Новости
- Образование
- Политика
- Праздники
- Приколы
- Природа
- Происшествия
- Путешествия
- Развлечения
- Ржач
- Семья
- Сериалы
- Спорт
- Стиль жизни
- ТВ передачи
- Танцы
- Технологии
- Товары
- Ужасы
- Фильмы
- Шоу-бизнес
- Юмор
A diferença entre git merge e git rebase #meme
Para entender a diferença entre `git merge` e `git rebase` de forma didática, vamos imaginar que o Git é um livro de histórias e cada commit é uma página escrita nesse livro.
Ambos os comandos têm o mesmo objetivo final: pegar as alterações que você fez em uma branch (digamos, `feature`) e trazê-las para a branch principal (`main`).
A diferença está em como eles contam a história dessa integração.
---
1. `git merge` (A Fusão)
O `merge` é como colar um novo capítulo no final do livro e adicionar uma **página de capa** dizendo: *"Hoje, eu juntei o Capítulo da Feature com o Capítulo Principal"*.
Ele preserva a história exatamente como ela aconteceu, incluindo o fato de que vocês trabalharam em paralelo.
Como fica o histórico visualmente:
```text
(main)
A --- B --- C
\ \
D --- E --- M (Novo "Merge Commit")
(feature)
```
O que aconteceu: O Git criou um novo commit (`M`) que tem dois "pais": o último commit da `main` (C) e o último commit da `feature` (E).
Vantagem: É 100% seguro. Não altera o histórico original. Se algo der errado, é fácil de entender o que houve.
Desvantagem: Se muitas pessoas fizerem merges o tempo todo, o histórico do projeto vira uma "teia de aranha" ou um "prato de espaguete", ficando difícil de ler.
---
2. `git rebase` (A Reescrita da Linha do Tempo)
O `rebase` (que vem de "re-base", ou seja, mudar a base) é como uma **máquina do tempo**.
Em vez de criar um novo commit de fusão, o Git pega os seus commits da `feature` (D e E), "desfaz" eles temporariamente, atualiza a sua base para o ponto mais novo da `main` (C) e **reaplica** os seus commits por cima.
É como se você dissesse: *"Fingiremos que eu comecei a escrever a minha feature DEPOIS que todas as atualizações da main já tinham sido feitas"*.
Como fica o histórico visualmente:
```text
(main)
A --- B --- C
\
D' --- E' (feature)
```
O que aconteceu: Os commits D e E foram "recriados" como D' e E' em uma linha reta, após o commit C. O histórico fica linear e limpo.
Vantagem: O histórico do projeto fica extremamente limpo, linear e fácil de ler (como uma linha reta)
#meme #dev #github #coisadedev
Видео A diferença entre git merge e git rebase #meme канала Coisa de Dev
Ambos os comandos têm o mesmo objetivo final: pegar as alterações que você fez em uma branch (digamos, `feature`) e trazê-las para a branch principal (`main`).
A diferença está em como eles contam a história dessa integração.
---
1. `git merge` (A Fusão)
O `merge` é como colar um novo capítulo no final do livro e adicionar uma **página de capa** dizendo: *"Hoje, eu juntei o Capítulo da Feature com o Capítulo Principal"*.
Ele preserva a história exatamente como ela aconteceu, incluindo o fato de que vocês trabalharam em paralelo.
Como fica o histórico visualmente:
```text
(main)
A --- B --- C
\ \
D --- E --- M (Novo "Merge Commit")
(feature)
```
O que aconteceu: O Git criou um novo commit (`M`) que tem dois "pais": o último commit da `main` (C) e o último commit da `feature` (E).
Vantagem: É 100% seguro. Não altera o histórico original. Se algo der errado, é fácil de entender o que houve.
Desvantagem: Se muitas pessoas fizerem merges o tempo todo, o histórico do projeto vira uma "teia de aranha" ou um "prato de espaguete", ficando difícil de ler.
---
2. `git rebase` (A Reescrita da Linha do Tempo)
O `rebase` (que vem de "re-base", ou seja, mudar a base) é como uma **máquina do tempo**.
Em vez de criar um novo commit de fusão, o Git pega os seus commits da `feature` (D e E), "desfaz" eles temporariamente, atualiza a sua base para o ponto mais novo da `main` (C) e **reaplica** os seus commits por cima.
É como se você dissesse: *"Fingiremos que eu comecei a escrever a minha feature DEPOIS que todas as atualizações da main já tinham sido feitas"*.
Como fica o histórico visualmente:
```text
(main)
A --- B --- C
\
D' --- E' (feature)
```
O que aconteceu: Os commits D e E foram "recriados" como D' e E' em uma linha reta, após o commit C. O histórico fica linear e limpo.
Vantagem: O histórico do projeto fica extremamente limpo, linear e fácil de ler (como uma linha reta)
#meme #dev #github #coisadedev
Видео A diferença entre git merge e git rebase #meme канала Coisa de Dev
Комментарии отсутствуют
Информация о видео
14 июня 2026 г. 22:52:46
00:00:06
Другие видео канала
