Git 用分支覆盖 Master

Git 用于跟踪我们正在使用的源代码；它还促进了协作并帮助我们将项目保持在当前状态。

当我们开发新功能时，它们的历史应该触手可及，因为它对于开发任何应用程序或文档都非常有帮助。

Git 用分支覆盖 Master

Git 有两种方法可以将更改从一个分支混合到另一个分支。一个是 rebase，另一个是与任何分支合并到另一个仓库分支。

本文将讨论从另一个仓库分支完全合并 Git 中的 master 分支。

在使用 Git 工作流时，我们对代码所做的更改必须最终在应用程序任务完成时在 master 分支中完成。

我们还必须了解，我们可能已经开发了一些其他分支，其中包含尚未准备好用于生产部署的代码更改，我们根据组织要求和规则将该分支命名为 dev。

在某些情况下，我们对 dev 分支进行了太多更改，然后在将 dev 分支与 master 分支结合时遇到困难；它不能轻易执行。

克服这种忙碌情况的一种方法是用 dev 分支完全取代我们的 master 分支。我们可以通过以下两种方式来完成它。

合并策略为 Ours

为了完成这个策略，我们将首先执行以下命令，在 ours 合并策略的帮助下将 dev 分支合并到 master 分支，如下所示。

git checkout dev
git merge -s ours master
git checkout master
git merge dev

合并中的选项 --strategy=ours 旨在替换功能分支的旧历史记录。现在我们的 master 将拥有 dev 的所有内容并忽略 master 中的所有更改。

通过应用此方法，我们将获得干净且安全的合并提交；使用这些分支的其他开发人员也可以从这种合并中受益，因为他们在合并其功能分支时不会遇​​到问题。

另一方面，这种方法的缺点是，如果我们的 dev 分支和 master 分支在项目中辐射到更大的规模，这种合并可能不起作用。

强制推送

另一种选择是强制以不同的名称推送 dev 分支，但这种方法与上述讨论的问题相比是野蛮的。

git push -f origin dev: master

在命令中提到的别名 -f 标志的帮助下，我们之前的分支 master 完全被 dev 分支覆盖，包括历史。

在应用上述方法时我们必须非常小心，因为它将删除 master 分支中存在的所有提交，因为它们在仓库的 dev 分支中也不可用。