具有來自master的合並提交的Git rebase遠程分支-這樣安全嗎？

Question

我們有一個共享的遠程分支（為簡單起見，在本示例中稱為Feature_branch）基於幾個人將提交推送到的master。 在開發過程中，我們必須兩次從主服務器合並才能進行一些必要的更改。 現在是時候將feature_branch的內容交付給master了，並且出現了一個問題：從master重新設置基礎然后再推送回master是否安全？

在示例中，我們已經從master分支出來，並在feature_branch中完成了一些提交（其他人已將提交推送到master分支）：

git checkout master
git pull --rebase
git checkout feature_branch
git pull --rebase
git merge master

然后，我們在feature_branch中做更多工作，其他人則將其他內容推向高手。 然后再次重復上述過程（因此，feature_branch中總共有兩個合並提交）。

現在，決定停止在feature_branch中工作，是時候交付給master了。 所有同事都被告知，並且由於團隊很小，每個人都坐在一個房間里，所以這不是問題。 要交付，我們可以這樣做：

git checkout master
git pull --rebase
git checkout feature_branch
git pull --rebase
git rebase master
git checkout master
git merge --ff-only feature_branch
git push

這樣安全嗎？ 我感覺這可能會引起問題，但是當我在本地嘗試此操作（除最終git push之外的所有操作）時，它實際上看起來不錯（僅在master上重播了feature_branch唯一提交）。 但是，即使有時它可以工作，在某些情況下還是有危險或不適當的，還是可以將其用作首選的工作方式（假設我們有時必須共享功能分支，要求不時將母版合並到其中）？

只是為了澄清一下，在這種情況下，我們對保留來自Feature分支的“絕對”歷史記錄（因為rebase將重寫feature_branch提交的歷史記錄）並不感興趣，我們只是希望將提交內容交付給master。

Answer 1

通常，我一直使用的方法是：1.檢出要素分支2.在主節點上對要素分支進行重新設置3.在進行基礎調整后，本地應該看到清晰的線性歷史記錄4.然后強行推動該局部特征分支的提交到遠程功能分支5.完成后，簽出master分支6.將feature分支合並到master分支並將提交推送到master

Answer 2

可能很危險。 最糟糕的情況是，當您將包含與其他提交不沖突的“邪惡變更”的“邪惡合並”作為基礎時。 重新部署時，此更改可能會默默丟失 。