在将git分支合并到develop/master之前是否有必要更新它？

考虑一个场景，其中我从master创建了一个名为“feature1”的分支。我的朋友还从master创建了一个名为“Feature2”的分支。他完成了代码更改，并将“Feature2”分支合并回master

---

现在，我已经完成了“功能1”分支中的更改，并希望合并回master（自从我分支它以来，它一直在更新）。在将“功能1”合并到主功能之前，我是否需要拉入/重设基础，或者这是git将处理的问题？

在将功能分支合并到主分支之前，无需更新主分支。然而，这不是最佳做法。您最好执行以下操作：

拉动主分支，确保它与您的遥控器是最新的

将主分支合并/重设为要素分支

修复任何合并冲突

将要素分支合并到主分支中

这样做将确保您的提交是历史上最新的，并且任何合并冲突都是在功能分支而不是主分支上处理的。这将使您的主分支保持干净，历史记录保持干净。使用你的回购协议的其他人会很高兴

命令将如下所示：

git签出主机

git pull--重新设置原点主控形状

git签出特性1

git重基主控器

解决任何冲突

git签出主机

git rebase feature1//将无冲突地重新设置基础，因为您以前已修复了它们

要详细说明每个命令的作用，请执行以下操作：

跳转到您的

主版本

，该版本已过时

从repo中提取更改并更新

master

，应用

master

顶部的任何本地更改（如果使用分支进行编辑，则无）

跳回您的

feature1

分支，该分支仍然基于过时的“master”

将

feature1

更改应用于

master

，后者在#2中更新

解决冲突

跳回

master

，它已更新，但仍然没有您的

功能1

更改

将

master

更改应用于

feature1

之上，但由于feature1是master的直接子项，因此这只是使用您的feature1更改再次更新master

这里你应该考虑<代码> Git Pux将“你的修改”发布到RePO

---

如果没有冲突，则应该合并。我更喜欢在合并之前进行重新基化，因为这会让历史看起来更好。如果您使用GitHub，它会显示一条消息，指示它是否可以合并而不发生冲突。我见过一个案例，在合并“Feature 1”分支后，没有重新基化/拉入，导致主分支中有一个不应该存在的文件。将“功能1”合并到主功能时没有冲突。步骤7不应该是git merge feature1？合并应该是在步骤1-6之后的快速推进。是的，步骤7应该是git merge feature1，然后是git push origin master。您能否详细说明“使用您的回购的其他人会很高兴。”我对这一点的想法随着时间的推移而发展，特别是当您处理具有许多贡献者的高度活跃的回购时。其中一些是个人和组织偏好，而不是必须遵循的规则。通常，在查看git历史记录时，如果历史记录是线性的，则更容易理解。因此，如果您正在处理规模较小的回购协议，通常最好进行重新基准以避免合并提交。高度活跃的回购，当

main

分支快速移动时，添加合并提交可能是获得更改的唯一方法。