À quoi servent git-rebase et git-merge ? Quelle est la différence entre git-rebase et git-merge ? L'article suivant vous présentera la différence entre git-rebase et git-merge. J'espère qu'il vous sera utile !
Utiliser Git pour le contrôle de version devrait être l'un des flux de travail que la plupart des ingénieurs rencontrent quotidiennement, mais ce que j'utilise n'est rien de plus que push, pull code>, merge, checkout ou log et d'autres commandes si vous allez plus en profondeur, vous ne pouvez pas comprendre cela pendant le processus. interview. Question : "Connaissez-vous la différence entre la fusion et le rebase dans Git ?" push、pull、merge、checkout 或 log 等几个指令，更深入一点就一问三不知了，在面试时被问到了这个问题：「你知道 Git 的 merge 和 rebase 有什麽不同吗？」
听完后我直接困惑，对我来说 rebase 就是用来整理 commit 的工具，居然还可以和 merge 做比较？【推荐学习：《Git教程》】
先来说说平常我会用 rebase 这个指令来干嘛，假如我新增了一个单元测试，然后 commit，这时候 log 就会多一条 commit 的纪录：
但是在 commit 完才发现，我少写了另一个测试案例，因此在补上之后，我又 commit 了一次：
这时记录中会多出另外一条 commit，不过对我来说，这两个 commit 在做的其实是同一件事，于是我在 push 到 remote 之前，就会想要先整理一下 commit，把这两条记录合并起来。
要把这两条记录合并起来有两个方法，第一个是 reset 到添加第一个测试案例之前，然后直接做一次 commit。第二个方法就是用 rebase 来处理！
首先让我们看看目前的 log：
我的目的是把 9dc67ff 和 87af945 整理成一个，所以要调整的 commit 是从 init, 也就是 commit id为 7eb57cb 之后的所有 commit，搭配上 rebase 指令的话就是：
git rebase -i 7eb57cb
输入完后就会跳到 vim 的编辑画面：
画面上会看到 7eb57cb 后的所有 commit（目前就只有 9dc67ff 和 87af945 ），接着把 9dc67ff 的 pick 改成 squash，表示把它与前一个 commit 做合并。先点一下 i 后开始用 vim 编辑内容：
编辑完后，可以点 esc 再输入 :wq 做保存，如果只是好奇进来玩看看，不想保存的话就输入 :q!。结束上面的流程后，再查看一次 log，会发现两条 commit 变成一笔了。保存完会跳到 commit message 的画面，这边可以让你输入合并后的 commit message，但我就不改了，一样直接保存：
结束上方的流程后，再查看一次 log，会发现两笔 commit 变成一笔了：
先 nice，上述的操作为 rebase 的 interactive mode，在 git rebase 后输入的 -i 其实就是 interactive 的缩写。
大家应该对 merge 指令都非常熟悉，因为在做新功能的时候，通常都会拉一个分支出去，完成后再 merge
Tout d'abord, parlons de ce que j'utilise habituellement avec la commande rebase. Si j'ajoute un nouveau test unitaire, alors 
commit, puis log code> aura. un autre enregistrement de <code>commit : 🎜
🎜🎜Mais j'ai découvert après le commit que j'avais manqué d'écrire un autre scénario de test, alors je l'ai ajouté. Après cela, je me suis engagé encore une fois : 🎜🎜🎜🎜À ce moment, il y aura un autre commit dans l'enregistrement, mais pour moi, ces deux commit sont je fais en fait la même chose, donc avant de passer à distance, je veux trier les commits et fusionner les deux enregistrements. 🎜🎜Il existe deux façons de fusionner ces deux enregistrements. La première consiste à réinitialiser avant d'ajouter le premier scénario de test, puis à effectuer un commit directement. La deuxième méthode consiste à utiliser rebase pour le gérer ! 🎜🎜Jetons d'abord un coup d'œil au journal actuel : 🎜🎜
🎜🎜Mon but est d'organiser 9dc67ff et 87af945 en un seul , Donc les commits à ajuster proviennent de init, c'est-à-dire que tous les commits après l'identifiant de commit sont 7eb57cb S'ils sont combinés avec la commande rebase, ce sera : 🎜. git checkout string-library
🎜🎜Vous verrez tous les commits après 7eb57cb à l'écran (actuellement seulement 9dc67ff et 87af945), puis changez le pick de 9dc67ff en squash, ce qui signifie fusionner avec le commit précédent. Cliquez d'abord sur i, puis commencez à éditer le contenu avec vim : 🎜🎜
🎜🎜Après l'édition, vous pouvez cliquer sur Échap et saisir :wq pour enregistrer. Si vous êtes juste curieux, entrez et jouez. Si vous ne souhaitez pas le sauvegarder, entrez :q!. Après avoir terminé le processus ci-dessus, vérifiez à nouveau le journal et vous constaterez que les deux validations ne font qu'un. Après avoir enregistré, vous accéderez à l'écran du message de validation. Ici, vous pouvez saisir le message de validation fusionné, mais je ne le modifierai pas et je l'enregistrerai directement : 🎜🎜
🎜🎜Terminer le processus ci-dessus Enfin , vérifiez à nouveau le journal et vous constaterez que deux commits ne font qu'un : 🎜🎜
🎜🎜Bien d'abord, l'opération ci-dessus est le mode interactif de rebase, entré après git rebase - je suis en fait l'abréviation de interactif. 🎜fusionnez une fois terminée. Revenez à la branche principale telle que master ou develop. Le déroulement de l'opération est le suivant : 🎜🎜🎜🎜在 merge 的时候会有两种情况，第一种是 fast-forward，会把被合并分支的 HEAD 的 reference 移到要合併分支内最新的 commit 上，上方操作的 merge 结果就是 fast-forward，master 的 HEAD 被移到 string-library 的最新 commit，画成图的话就是这样子：
但是如果在执行 merge 的时候产生冲突，那分支的合并行为就会和 fast-forward 有点不同了。举例来说，我分别在 master 和 string-library 的同一个文件添加内容，那当我执行 merge 的时候就会要求先修复冲突：
修复完后，再执行 commit 完成合并，而这一次合并时，会再多一个 commit 是有关 merge 了 string-library 分支的纪录：
这个情况画成图就会像这样子：
看完上方对 rebase 和 merge 的介绍后，你也许会想说：
「咦？那这两个不是完全不同的东西吗？」
对的，原本我也是这麽认为，一直到我去看了 git-rebase 的文档，才发现原来我一直误会它了。在 git book 的 rebase 篇章，第一段就说明了，在 Git 里有两种方法可以用来整合两个分支，而这两个在上方都有提到，分别为 merge 和 rebase：
从上方的 merge 例子已经知道了，merge 在合并的时候会有 fast-forward，和冲突时用一个 commit 记录合并变更的两种情形。而 rebase 的整合方式非常有趣，依照关于 rebase 的另一段说明，它可以「把某个分支中所有 commit 的过程，以另一个分支的 commit 为基础重播一遍」：
这是什麽意思呢？首先让我们回到上述的例子，并在 master 分支上用 reset，让 master 的版本回到合并 string-library 之前：
现在我们要用 rebase 指令，将 string-library 所有的 commit 修改，以 master 的 commit 为基础跑一次。使用 rebase 合并的第一步，要先切到想重播 commit 的分支：
git checkout string-library
然后再输入 git rebase 指令，并于后方指定要在哪个分支上重播：
git rebase master
执行结果：
在 rebase 重播 commit 的过程中，和 merge 相似的地方在于，如果有冲突的话还是需要解决，但在解决后，并不是使用 commit 指令进行合并，而是要输入 git rebase --continue，让 rebase 可以继续重播接下来的 commit：
重播完成时，会显示目前重播到哪个 commit，以 string-library 来说就是最新的add string unit test D。这时候的分支关系，画成图就会变成：
上图在经过 rebase 之后，string-library 里 07e38fb 修改，会以 master 的 commit 为基底再重播一次。
需要注意的是，重播后的 commit id 会和原本的不一样，这等于完全改写了分支内所有的 commit 历史纪录。
De plus, après avoir exécuté le rebase, string-library n'a pas réellement été fusionné avec la branche master, vous devez donc toujours revenir à la branche master pour exécuter la fusion et terminer la fusion : string-library 其实还没有被合并回 master 分支上，因此还是要再切回 master 执行 merge，以完成合併：
因为已经先用 rebase 在重播时处理完 commit 的冲突了，所以现在 merge 就会直接走 fast-forward 合并，也不会另外多一个 merge 的 commit 纪录。
优点
不会在合併时产生多馀的 commit。
可以在重播的时候以 commit 为单位处理冲突。
合併时会依分支的 commit 排列，能够比较清楚的 review issue 或 feature 处理的过程。如果使用 merge，在合併后就会依照时间顺序穿插排列两个分支的 commit。
在贡献开源项目的时候，如果在 push 前先做 rebase，那作者就能够直接以 fast-forward 的方式合并，不需要再另外解冲突。
缺点
最大的缺点就是上方提到的，使用 rebase 会修改 commit 的历史纪录，如果在自己的 local 整理 commit 或是分支那还好，但如果不小心去异动到 remote 的分支，然后又更不小心用了 git push -f，那可能就会被同事讨厌，或被投稿到纯靠北工程师。
在查了一些资料后，发现 rebase 和 merge 都各有拥护者，我先阐述他们的想法，再主观提一下自己的观点。
支持 git-merge 派的工程师们认为，版本纪录有价值的地方就在于项目的 commit，也就是这个项目的「历史实际上发生过哪些事情」，如果你去修改了这些历史纪录那就很不好。因此即使不同分支的内容在 merge 后都混在一起，但这些内容仍然说明了这个项目的历史。
支持 git-rebase
git push -f, vous pourriez être détesté par vos collègues, ou vous pourriez être soumis à un ingénieur purement nordique. 🎜🎜🎜Dois-je utiliser git-rebase ou git-merge ? 🎜🎜🎜Après avoir vérifié certaines informations, j'ai découvert que le rebasement et la fusion ont tous deux leurs propres partisans. Je vais d'abord expliquer leurs idées, puis mentionner subjectivement mes propres opinions. 🎜🎜🎜git-merge Pai🎜🎜🎜 prend en charge git-merge. Les ingénieurs de Pai pensent que la valeur des enregistrements de version réside dans les commits du projet, c'est-à-dire dans "l'historique de ce projet qui s'est réellement produit". " "Quelles choses", ce serait très mauvais si vous modifiiez ces documents historiques. Ainsi, même si les contenus des différentes branches sont mélangés après la fusion, ils illustrent néanmoins l'histoire du projet. 🎜🎜🎜git-rebase faction 🎜🎜🎜 prend en charge git-rebase. Les ingénieurs de la faction estiment que le commit parle du "processus d'évolution" de ce projet. Ce qui est important, c'est ce qui se passe, même si. il est modifié L'historique du commit a été supprimé, mais ce qui s'est passé n'a pas changé Puisque nous pouvons utiliser un enregistrement plus clair et plus concis pour que les générations futures puissent le lire, nous devrions le faire. 🎜🎜🎜Opinion subjective personnelle🎜🎜🎜Personnellement, j'utilise toujours git-rebase pour modifier les commits afin de rendre les enregistrements historiques plus simples et plus faciles à lire, mais l'utilisation est limitée avant de pousser à distance si les enregistrements ont été poussés à distance aujourd'hui. , alors peu importe le désordre, je ne les modifierai pas. Après tout, les enregistrements distants sont partagés par tout le monde. Si je ne les modifie pas à volonté, je respecte les autres membres de l'équipe. 🎜🎜【Recommandation de didacticiel vidéo connexe : 🎜front-end Web🎜】🎜Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
Construisez votre propre serveur git
La différence entre git et svn
git annuler le commit soumis
Comment annuler l'erreur de commit git
Comment comparer le contenu des fichiers de deux versions dans git
Que dois-je faire si la carte d'itinéraire ne peut pas être ouverte ?
commande de renommage de fichier Linux
Quelle est la raison pour laquelle le réseau ne peut pas être connecté ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
