在開發中，通常會保持兩個分支master分支和develop分支，但是如果因為develop上面迭代太多而沒有及時維護master，最后想丟棄master而直接將測試確認過的develop強推到master，該怎么操作呢？
網上搜了一下，但是真正自己使用起來卻又暴露出各種問題。因此，做如下總結分享，希望對遇到同樣問題的人用幫助。
- 場景一：master下有a.txt文件，develop下有a.txt（和master保持一致），b.txt文件（追加文件），c/c.txt文件（追加文件夾和文件）。
- 場景二：master下有a.txt文件，develop下有a.txt（追加自己內容），b.txt文件（追加文件），c/c.txt文件（追加文件夾和文件）。
- 場景三：master下有a.txt文件（追加自己內容），develop下有a.txt（追加自己內容），b.txt文件（追加文件），c/c.txt文件（追加文件夾和文件）。其中master的a.txt和develop的a.txt不存在競合。
- 場景四：master下有a.txt文件（追加自己內容），develop下有a.txt（追加自己內容），b.txt文件（追加文件），c/c.txt文件（追加文件夾和文件）。其中master的a.txt和develop的a.txt存在競合。
網上查找了一個操作步驟，如下：
- 切換到develop分支下，並保證本地已經同步了遠端develop的最新代碼
git checkout develop git pull - 把本地的develop分支強制(-f)推送到遠端master。
git push origin develop:master -f
- 切換到舊分支master。
git checkout master
- 將本地的舊分支master重置成最新的develop分支。
git reset --hard develop
- 再推送到遠端倉庫。
git push origin master --force
或使用下面的命令，將當前分支推送到遠程的同名分支。
git push origin HEAD
針對上面的步驟，如果你使用的sourcetree管理的GitHub代碼，恭喜你，你成功中招了，場景一和場景二在沒有修改同一個文件的情況下，上面的五部曲一點問題沒有。但是，凡是就怕但是。
如果你對同一個文件進行過維護而導致差異，即便不是同一個代碼，都會導致問題產生。分析后發現，問題點主要在步驟4上面，當本地的舊分支master的a.txt文件與最新的遠端分支master的a.txt有沖突，需要你手動去判斷需要merge操作。
這在很少的文件與很少的修改點的情況下，可能你還很好判斷，但是如果文件數量龐大，且修改點因時間久遠忘記了的情況下，可能我就只能說呵呵了。這也就沒有達到標題所說的強制合並的效果。
在知道了上面問題的症結后，我將上面的步驟做了修正，如下：
- 切換到develop分支下，並保證本地已經同步了遠端develop的最新代碼。
git checkout develop git pull
- 把本地的develop分支強制(-f)推送到遠端master。
git push origin develop:master -f
- 切換到舊分支master。
git checkout master
- 下載遠程倉庫最新內容，不做合並。
git fetch --all
- 把HEAD指向master最新版本。
git reset --hard origin/master
再執行上面的場景三和場景四，順利執行完，切換到sourcetree上面，也不會再提示有競合需要手動merge的操作，也沒有需要你push和pull的東西，完美。
分析上面的操作，雖然核心操作是步驟2，因為經過步驟2，遠端的master已經被你用develop強制替換了，目的是達到了，你完全可以在本地另起一個路徑再clone一份master進行管理。
但是，在經過了改良后的操作后，你完全可以不丟棄已經使用很習慣了的路徑，何樂而不為呢。
再說改良后的修正點核心思想：就是獲取遠端的GitHub文件信息，而不做合並，然后直接丟棄本地舊的代碼，直接獲取遠端分支的代碼覆蓋到本地，OK，問題解決，希望對大家有用。