更新 - 重讀你的帖子，我意識到我完全錯過了merge --squash問題......事實上，rebase的方法，我形容是基本相同，做一個merge --squash，與它更容易重複的差異。 （那麼，我不知道--squash，因爲我是n00b。）
無論如何，您對做merge --squash的關注是該分支「基本上是分歧的」。這是真的;如果你這樣做的話（或者按照下面略述的重新定義），在D和d提交之間沒有git血統鏈接。但只要你跟蹤有多少wip已被壓扁到dev，它不會使任一分支無用 - 它們的內容沒有發散，只有拓撲。 （所以這就是爲什麼移動一個標籤來表示你最後的--squash或rebase可以讓你擺脫困境。）
但是如果你想保持拓撲關係，那麼--no-ff合併就是要走的路。問題似乎是，你喜歡一些關於有D知道它來自d的東西，以及一些關於它不知道的事情;所以你必須決定你寧願選擇哪一個。
如果它知道，那麼例如默認log將顯示更細粒度的歷史記錄（但具有正確的選項可以覆蓋該歷史記錄）。如果它不知道，那麼未來在簡單merge上的嘗試將會使git交叉，並且您必須自己跟蹤「真正」上游（內容方面），例如下面示例中的rebaseUpstream標記。
那麼，你的文字和你的照片並沒有說完全一樣的東西。
圖片是您通過簡單合併--no-ff選項而獲得的。所以，當dev爲A和wip爲d，你融入dev創建D - 單個提交其以dev，代表你b，c，並d做了wip一切。
現在你可能認爲我是錯誤的，因爲如果你從dev做git log你仍然可以看到b，c，並d作爲單獨提交。這是因爲git試圖幫助您完全瞭解D的歷史記錄，並且爲了防止它會給git log--first-parent選項（使其僅在dev分支中「向上」）。在這種情況下，您需要確保您的合併提交具有良好的提交消息。
但是你寫的你想要的是不同的 - 也可以做，但有點毛。如果你做了一個壓縮和重組，D不會是d的孩子 - 這就是爲什麼我說你的照片顯示合併。
訣竅使之與rebase工作是瞭解rebase不破壞承諾，即使在正常使用中它看起來好像沒有。你可以看到它不是通過讓兩個分支指向同一個提交，並將其中一個分支重新綁定。事實上，這就是你如何做你想問的問題。
但被警告：這種方式的瘋狂謊言。
所以我們回到你的圖表。在開始時，您在A處有dev和wip。在此處放置標籤，因爲我們總是想知道wip已有多少dev。
git tag rebaseUpstream
現在做一些工作，根據您所需的工作流程，直到你在d有wip。然後
git checkout -b rebaseTip
git rebase --interactive --onto master rebaseUpstream
現在你在待辦事項列表編輯器，因此從pick改變c和d說明squash，然後讓「呃裂口。那麼當然你可以編輯壓扁的提交信息。
現在你有發展的兩條線，指了指dev - 一個只有D和一個與b，c和d。接下來我們需要更新dev。
git checkout dev
git merge rebaseTip
git branch --delete rebaseTip
現在有了這個麻煩的是Git並不知道D和d有任何關係。另一方面，這意味着git log或類似的，當完成dev時，將顯示你所希望的 - 無需額外的選擇。但壞消息是，如果你不小心，你會失去多少在dev。爲了降低這種風險
git checkout wip
git tag -f rebaseUpstream
現在你可以恢復你對wip分支流程，並重復整個事情往往你喜歡。
_I不能只南瓜rebase_的提交。從技術上講，只要_you可以肯定，沒有其他人使用** wip **分支。 – pathfinderelite
是的，我想過，因爲這個想法確實是** wip **分支只應該是我的。我對事故有點擔心，認爲可能有更好的方法可以避免這個潛在的問題。也許我不應該關注它自己，只是指定分支來反映它本身就是我的。 – cgbrown