場景一：
- 我在本地和遠程存盤庫中都有“主”分支
- 我創建了一個“feature-1”分支并在其中進行了一些提交。
- 將“feature-1”分支合并到“主”分支
- 將更改推送到遠程“主”分支
場景二：
- 我在本地和遠程存盤庫中都有“master”和“feature-1”分支
- 我在本地 'feature-1' 分支中很少提交
- 我將這些更改推送到遠程“feature-1”分支
- 在遠程服務器（GitHub）上將“feature-1”與“master”合并
兩種方式都有效。那么每種方法在什么情況下使用呢？
uj5u.com熱心網友回復：
只是為了澄清：
該問題被標記為git。根據這些條款，情景 2不存在。Git 絕對會拒絕在服務器端執行合并。它沒有這樣的規定；確實，這是被禁止的。這就是為什么您不能推送到具有您在本地沒有的提交的分支的原因。
但是，一些 Git 托管站點，例如 GitHub，已經創建了一種稱為“拉取請求”或“合并請求”的機制，看起來像是在服務器端執行合并。這種機制不僅涉及最終合并，還涉及差異的顯示（通過 Web 瀏覽器）以及在合并之前對其進行評論的能力。這是為了允許多個協作者在合并發生之前審查彼此在分支上的作業。許多作業場所在 GitHub 上安裝規則，禁止將本地合并提交推送到主分支；合并必須通過拉/合并請求的方式執行，并且在分支得到協作者明確批準之前，合并將被禁止。
所以規則很簡單：
如果您一個人作業，請在本地合并。
如果您與其他希望獨立創建要合并到主分支的分支的協作者共享此存盤庫，那么一定要利用服務器端的拉/合并請求來促進協作，并配置規則以強制執行無論您的政策是什么。
uj5u.com熱心網友回復：
最終結果實際上是相同的，但是如果您必須遵守審查流程，您將需要推送您的功能分支，然后創建拉取或合并請求，然后在審查和批準后遠程合并。
uj5u.com熱心網友回復：
簡單的場景 2，因為更多的同事有機會在需要時對其進行審查，也可以在推送時運行任何需要的管道等。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/485402.html
標籤：混帐