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
分支中也不可用。
Abdul is a software engineer with an architect background and a passion for full-stack web development with eight years of professional experience in analysis, design, development, implementation, performance tuning, and implementation of business applications.
LinkedIn