我可以將推送的提交從一個分支移動到另一個現有分支嗎？

Question

我有3個分支： develop ， feature-1和feature-2 。 我當時正在研究feature-1 ，然后切換到feature-2 。 然后，我完成了feature-2工作，提交並推送到存儲庫，然后為該功能創建了一個合並請求。 然后，我看到feature-2包含一些應該在feature-1提交。 我可以將它們從feature-2本地移動到feature-1 ，然后在存儲庫中反映相同的移動嗎？

Answer 1

git cherry-pick <commit-id>是您的朋友，親愛的。

1. 繼續Feature-2分支
2. 將要從feature-2移動到的commit-id(s)復制到feature-1
3. 切換到功能1分支

4. 現在，櫻桃選擇您在上面的步驟2中復制的所有提交。

   git cherry-pick <commit-id>

   如果您有多個提交要移至feature-1則將所有提交ID依其提交日期/時間排列。

   例如：

   git cherry-pick <commit-id-1> <commit-id-2> . . <commit-id-n>

Answer 2

您的問題是，所涉及的提交屬於feature-1而不屬於feature-2 branch 。 接受的答案不能完成此任務。

cherry-pick是在一個分支上創建新提交的一種好方法，該提交可以復制另一分支上的提交所做的更改。 但它不會更改另一個分支。

例如，如果您開始

x <--(master)
|\
| A1 -- A2 <--(feature_1)
 \
  B1 -- A3 -- B2 <--(feature_2)

A3是用於feature_1 ，在執行了選擇cherry-pick步驟之后，您將擁有

x <--(master)
|\
| A1 -- A2 -- A3' <--(feature_1)
 \
  B1 -- A3 -- B2 <--(feature_2)

因此feature_1看起來像您現在想要的一樣，但是feature_2仍然有一些可能不應該的更改。 將兩個功能都合並到master時，這可能會引起一些麻煩。 （我的意思是，可能存在合並沖突，但並沒有多大意義git確實會在這里提供幫助，但它並不完美。）

在您的問題中，您注意到提交已經被推送，並且響應於“ cherry-pick回答，您詢問更改是否可以干凈地push ； 因此，我認為您已經（至少在某些情況下）遇到過在您推送的分支上重寫歷史記錄的問題。

雖然這是事實，該結果cherry-pick會push干凈，那是因為在cherry-pick沒讓你自找的（如上所述）的所有更改。 這是對feature-2的修復，實際上導致了push問題。

一種解決方案是使用cherry-pick來修復feature-1 ，然后使用revert來修復feature-2 。 在我們的示例中，使用feature-2~1作為標識要“移動”的提交的表達式（通常可以使用提交ID或適合實際情況的表達式）：

git checkout feature-1
git cherry-pick feature-2~1
git checkout feautre-2
git revert feature-2~1

給你

x <--(master)
|\
| A1 -- A2 -- A3' <--(feature_1)
 \
  B1 -- A3 -- B2 -- !A3 <--(feature_2)

這仍將push干凈（因為沒有提交從任何一間分行的歷史刪除）和兩個分支現在有正確的改變。 從好的方面來說，這使您不太可能遇到合並問題； rebase一面是，某些rebase操作現在可能會出現問題。 還有，你可能采取的減輕步驟，但如果你擔心只是做的更改push干凈，那么你不會做那種rebase反正。

如果有很多提交要“移動”，那么您可能想要用交互式rebase替換cherry-pick ，如下所示：

git checkout feature-2
git branch temp
git rebase -i feature-1 temp

將打開一個編輯器，顯示一個用於rebase的“待辦事項”列表。 列表上的每個條目都是有關如何處理提交的說明。 刪除要“留下”的提交行。 （您還可以對提交如何在feature-1上表示的方式進行其他調整；但這是一個漫長的兔子漏洞，因為到目前為止您所要問的是如何“移動”提交，因此只需執行以下步驟即可“按原樣”。）

當你保存並退出編輯器，在rebase將開始，重寫所有選定的提交。 完成更新到feature-1

git checkout feature-1
git merge temp
git branch -d temp

您仍然需要轉到feature-2來還原不應存在的提交； 您可能想在帶有-n標志的單個命令中執行此操作，以便僅創建單個還原提交。 （這將有減少我上面提到的風險一定的，的副作用rebase演戲了，你做的作業后revert ;但同樣，我希望你不會做這些類型的rebase都會給出這個隱含的約束題。）

現在，有些人不喜歡將revert用於這種情況，因為歷史記錄顯示了發生的情況-包括進行更改以及以后刪除更改，這似乎很煩人，因為不應該進行更改。

避免的唯一方法是“改寫歷史”的feature-2 ，無論你怎么做，不會push干凈。 你可以得到它的push ，但這樣做你會為所有誰擁有副本的其他開發人員創建工作feature-2 -如果他們這樣做了錯誤的事情，這將撤消你的工作。 因此，如果要重寫歷史記錄，則必須與使用該存儲庫的其他所有人進行協調。 有關此問題的更多信息，請參見“從上游rebase恢復”下的git rebase文檔。