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 分支中也不可用。