Git rebase補丁文件在錯誤的地方

Question

我不確定這是git rebase的有意和已知的操作，或者如果我發現問題。我已經使用lorem ipsum將其複製到公共存儲庫中。 （https://github.com/drewclauson/git-rebase-example）

如果我有兩段代碼幾行完全相同（see lorem ipsum.txt），則會出現此問題。理想情況下，代碼將被重構以保持乾燥，但我不知道同一文件中存在重複代碼。

branch1有一個承諾master沒有，反之亦然，所以我將branch1重新編號爲master。

branch1'schange is adding a line between lines 23 and 24。 （「Test add a line of code」）

master'schange is editing line 23。 （插入23行上的「NEW TEXT」）

當我將branch1重新設置爲master時，從branch1's提交的更改得到patched in between lines 8-9而不是第24-25行。

我不太瞭解git的操作，但我假設它與應該添加24和25之間的行的提交的上下文有關？基本上，它希望根據前後的線條進行修補，並且由於文件的前面有相同的代碼，它只是在不考慮線數的情況下拋出修補程序？還是有我失蹤的東西？

謝謝，我仍然是一個相對新手git，所以它可能是，我只是不明白的東西。

Answer 1

正如您懷疑的那樣，Git會找到匹配的上下文並將更改應用到它。通常如果rebase成功而沒有衝突，一切都很好，但有時候不會。總是根據需要驗證結果並輸入fixup。

理想情況下，你不會有這種重複來讓Git跳起來，但還有其他的方式可能導致在成功的rebase之後很難避免的提交失敗。例如，假設我們有一個分支，它在一些函數foo()中添加了一個使用變量x的代碼塊。現在想象一下，有人決定x不是一個描述性名稱，並將其重命名爲foo_counter。如果我們將分支重定位到master上，那麼即使結果提交將無法編譯，我們的代碼的文本合併也很有可能會成功（因爲我們指的是從未聲明的變量）。在這種情況下，我們需要修復重新承諾使用foo_counter而不是x。再次，總是驗證rebase的reslt。

這提示了與合併相比，重新綁定的缺點之一，而這在新的Git用戶中往往會丟失。合併保留了原始分支上的提交，因此只需要驗證最終的合併提交。但是，對於重定位，每個重新提交的提交都必須進行測試，以避免降低存儲庫的完整性。通常情況下，重新分配的分支將被固定，並在頂部進行額外的提交，使中間提交處於不可測試狀態。即使最終結果看起來沒問題，也可能發生這種情況。這看起來可能並不重要，但如果您曾經使用過Git的bisect，那麼您將會體會到可測試的歷史記錄。並不是說這不能通過重新組裝來實現，而只需要更多的工作。