Git工作流程是否可以進行部分合並？

Question

我有兩個分支機構dev和a 。 我需要將功能a合並到dev ，但是我的隊友已經在一個尚未准備好合並的文件中創建了某些功能。 如果我只是使用我的合並和解析，則git將此文件中的更改標記為無效，而不是允許這些更改在以后合並，如果我嘗試重新合並分支，請快速前進。 如果我不解決沖突，則git拒絕執行合並。

解決此問題的策略是在旁邊創建一個分支並抑制損壞的功能，然后在該分支中合並。 問題是為此的git命令變得有些復雜，因此我需要專家的幫助。

我想盡可能將這種類型的動作推廣到git擴展中，我稱之為git-cherrymerge 。

步驟如下：

1. 將用戶指定的提交（也許可以通過某些策略自動執行）重播到臨時分支上
2. git filter-branch刪除損壞的文件
3. 壓榨臨時分支，添加自動提交消息
4. 將臨時分支合並到目標分支（此處為dev）

我不是很專家filter-branch或rebase ，它看起來像我可以很認真地濫用武器傷害的歷史 。

我想我的問題是

1. 請問這項工作還是有更好的規范方法來做到這一點？
2. 我應該按什么順序執行什么git命令，以免意外損壞存儲庫歷史記錄。

Answer 1

您基本上有一個正確的想法，您想要將一個分支變成兩個分支：一個分支，其中包含准備就緒的內容，另一個分支是未完成的更改。 例如，一個分支可能包含大量重構和錯誤修復，這些錯誤與不完整的功能交錯在一起。

A - B - C - D [master]
         \
          R1 - B1 - F1 - R2 - B2 - F2 [feature]

R1和R2正在重構更改。 B1和B2是錯誤修正更改。 F1和F2是不完整的功能。 您想要的是：

A - B - C - D [master]
         \
          R1 - B1 - R2 - B2 [fixes]
                           \
                            F1 - F2 [feature]

在那里有兩個步驟，重新排列提交並聲明新分支。 使用git rebase -i重新排列提交。 這將顯示如下內容：

pick f37beee Refactor 1
pick 7f238ea Bugfix 1
pick d100dd2 Feature 1
pick aa1124b Refactor 2
pick beadbee Bugfix 2
pick 0123abc Feature 2

然后，您實際上可以在編輯器中對它們進行重新排序。

pick f37beee Refactor 1
pick 7f238ea Bugfix 1
pick aa1124b Refactor 2
pick beadbee Bugfix 2
pick d100dd2 Feature 1
pick 0123abc Feature 2

Git將通過以新順序應用這些補丁來重建分支。 您可能必須解決沖突。 有關更多信息，請參見在Pro Git中重寫歷史記錄 。

然后，您需要聲明一個新分支。 僅僅是git branch fixes beadbee從聲明的最后一次提交開始聲明fixes分支。

正常情況下，將修補程序合並到主服務器中，然后在主服務器上重新建立功能。

---

但是，提交通常不是那么整齊地分開。 如果您的提交包含多個更改，並且只需要其中的一些更改，則可以將其轉換為多個提交。

像以前一樣使用git rebase -i ，但是將要拆分的提交設置為edit而不是pick 。

pick f37beee Refactor 1
pick 7f238ea Bugfix 1
pick aa1124b Refactor 2
pick beadbee Bugfix 2
edit beacd4a Messy commit
pick d100dd2 Feature 1
pick 0123abc Feature 2

然后，Git將停止該提交，並允許您按自己的喜好對其進行編輯。 使用git add -p僅將部分更改添加到登台區域（在其中構建提交），而git commit僅git commit部分更改。 這樣做直到每個更改都有自己的提交。 例如，也許它更改了方法的名稱，修復了錯誤，還更改了不相關的方法。 您將其分為三部分：一處更改名稱，一處修復錯誤以及一處更改不相關的方法。

您可以在Interactive Staging中了解有關此內容的更多信息。

---

我不是過濾器分支或重新設置基准方面的專家，並且看起來我很可能會因濫用它們而嚴重破壞歷史記錄。

是的，但是您可以扭轉這些錯誤，除非您git push ，否則不會影響任何其他人。 Git不會重寫歷史記錄，而是會編寫新的歷史記錄並假裝一直都是這樣。 過去的歷史仍然存在了一段時間，您可以使用ORIG_HEAD和git reflog類的東西來追溯到過去。

最壞的情況是， 刪除本地存儲庫並克隆一個新的存儲庫 。

Answer 2

由於這是最普遍的情況，因此我將Schwern的答案標記為正確的答案 -但值得注意的是，對於我的情況，有一個非常簡單的策略如下。 由於我打算壓縮所有更改，因此這意味着該過程可以在一次提交中完成。 仍然有必要創建一個新分支，但是可以使用軟復位快速完成。 如果您要推遲的更改數量很少且易於管理，那么我建議您采用這種策略

1. 檢出A
2. 分支到臨時分支
3. 將Git軟重置為A的“根”
4. 提交更改（不包括不需要的更改）
5. 合並develop