git rebase在其他分支上

Question

給出以下場景：

• 我們在不同的主題分支上開發功能。
• 在發布之前，我們將所有主題分支合並master分支。 然后在該分支上開始持續集成
• 此外，我們還直接在主分支上進行小的更改（拼寫錯誤等）
• 如果一切正常，我們將所有更改從主分支合並到relase分支。 然后將發布此版本分支

只要我們的測試沒有任何問題，這個工作流程就可以了。 但是一旦我們決定不從主人那里發送一個功能，我們就會遇到麻煩。

例如：

• 我們有5個不同功能的主題分支
• 我們將它們全部合並master
• 除此之外，我們直接在master上有兩個單獨的提交（我們修正了一些拼寫錯誤）
• 現在我們發現，5個功能中的1個沒有按預期工作，我們無法發貨
• 我們仍然希望發布其他4個功能（+ 2個直接在master上提交的提交）

我們現在唯一的選擇是： - 將4個主題分支直接合並到發布中 - 櫻桃選擇master上的2個提交到發布

這可能相當煩人，特別是當我們不跟蹤直接在master上進行的提交並且數量增加時。

我想有一個場景，我們能夠：

• 查看所有提交（或更好：合並的分支）
• 丟棄我們在下一個版本中不想要的所有更改
• 將所有其他更改合並到發布中

我已經做了一些研究並遇到了git rebase 。 git rebase --interactive非常接近我的預期。

最好的方案是：

• 將所有更改從master更改為交互式發布
• 刪除我不需要的所有提交（或更好的分支）
• 發布只有我想要的更改

然而問題是：

當我做：

git checkout master
git rebase --interactive release
<changes>

我最終修改了主分支而不是發布分支。 添加--onto release選項也無濟於事。

是否有可能在另一個分支上提交rebase的結果？

對萊夫說

Answer 1

我對這個問題的理解是你將5個不同的分支合並到master中，然后，在合並到release之前，你會發現其中一個有錯誤，所以你只想保留其他4個。

在這種情況下，你為什么不git revert錯誤分支的合並提交並繼續其余的？ 有什么我想念的嗎？

Answer 2

為了將來參考，請查看還原錯誤合並 ，這解釋了“撤消”合並的一些方案。 另外，請參閱Git rebase手冊中的警告， 從上游Rebase恢復和Pro Git中的警告- 重寫歷史記錄 。 如果您還沒有，請查看Git項目的工作流程和成功的Git分支模型 。

未來更好的工作流程可能是將功能分支合並到發布分支上，並且只有在通過測試，QA，用戶接受等之后才將發布分支合並到master 。我通常在發布日期之前等待合並。 您始終可以在發布日期之前進一步進行測試合並，以確保不會出現任何合並沖突意外。

為了解決您當前的情況，假設我們有兩個修復提交和五個功能分支合並提交的以下歷史記錄：

$ git --no-pager log --oneline --decorate --all --graph
*   e202262 (HEAD, master) Merge branch 'f5'
|\  
| * d9930ca (f5) f5
* |   f9d743b Merge branch 'f4'
|\ \  
| * | eea7737 (f4) f4
| |/  
* |   c84ad9f Merge branch 'f3'
|\ \  
| * | 135c7f7 (f3) f3
| |/  
* |   65ed393 Merge branch 'f2'
|\ \  
| * | 9a9b5b6 (f2) f2
| |/  
* |   76ae0e8 Merge branch 'f1'
|\ \  
| * | 8a02982 (f1) f1
| |/  
* | ace81a9 fix 2
* | d4b32e1 fix 1
|/  
* ab6d5b0 A

我會做的是：

1. reset master reset為ab6d5b0提交。
2. 創建release分支。
3. 將fix 1和fix 2提交添加到發布分支。
4. 假設f2是有問題的特征，將f1 ， f3 ， f4和f5分支合並到release分支上。
5. 雖然測試正在進行，做一個預演合並release到master 。
6. 如果一切都好，請將release合並到master 。

以下是使用上述歷史記錄執行這些步驟的命令（有關這些命令的更多信息，請參閱Git參考手冊 ）：

# Reset master to before the fix and merge commits
git checkout master
git reset --hard ab6d5b0
# Create a release branch
git checkout -b release
# Add the fix commits back
git cherry-pick d4b32e1
git cherry-pick ace81a9
# Merge feature branches
git merge f1
git merge f3
git merge f4
git merge f5
# Dry run merge
git checkout master
git merge --no-ff --no-commit release
git reset --hard HEAD
# Merge release to master
git checkout master
git merge --no-ff release

這將為您留下以下歷史：

$ git --no-pager log --oneline --decorate --all --graph
*   e24c16e (HEAD, master) Merge branch 'release'
|\  
| *   d23369a (release) Merge branch 'f5' into release
| |\  
| | * d9930ca (f5) f5
| |/  
|/|   
| *   8b90602 Merge branch 'f4' into release
| |\  
| | * eea7737 (f4) f4
| |/  
|/|   
| *   926c094 Merge branch 'f3' into release
| |\  
| | * 135c7f7 (f3) f3
| |/  
|/|   
| *   e964e13 Merge branch 'f1' into release
| |\  
| | * 8a02982 (f1) f1
| |/  
|/|   
| * bb5f6f5 fix 2
| * e8ffeef fix 1
|/  
| * 9a9b5b6 (f2) f2
|/  
* ab6d5b0 A

由於發布准備是在單獨的分支上完成的，因此master保持干凈，並且可以減輕由於功能選擇問題導致的發布管理難題。