在單獨的提交中添加依賴項？ （最佳實踐）

Question

假設我將一些新功能添加到現有的C模塊（它可以是任何語言，但我們將使用C作爲示例）。假設模塊是二叉搜索樹，我想添加三個新函數：preOrder（），postOrder（）和inOrder（），每個函數遍歷樹（不同地）並在每個節點上打印數據。我們還要說這些函數都依賴於一個新的依賴關係，稱之爲libprettyprint。

要將新的依賴項添加到項目中，我必須將#include行添加到模塊實現（.c文件），並編輯一些Makefile規則。

我將把我的3個新函數中的每個函數放在不同的提交中，這樣他們可以很容易地被接受，更改上游的礦石被拒絕。但至少有兩種不同的方式來處理新的依賴關係：

方法一： 我會添加#include，更改makefile，並編寫我的第一個函數。然後我會承諾。然後我會寫另外兩個函數，並分別執行其中的每一個。 （總共3次）

方式二： 我可以做一個非常小的提交，只需#include和更改後的Makefile，然後在三個單獨的提交中提交三個函數。 （總共4次）

對我來說方式一更糟，因爲如果項目維護人員/我的老闆拒絕了第一次提交但接受了其他兩次，他們將刪除#include和編輯後的Makefile，另外兩個提交將無法編譯。方式二解決了這個問題。

我的問題是，在現實世界中，總是使用方式二是值得額外的努力？還是隻是使提交日誌和浪費時間複雜化？

Answer 1

從我的POV，你

• 忘記方式0
• 必須始終牢記：使用方法是重 reviewer-和習慣依賴（即在一個地方好是壞在另一團隊）

我（個人）喜歡使用和快樂從同事僱員側路零看到：

邏輯任務完全包含在一個邏輯完成的提交中。你添加了三個函數，這個添加要求：1）包含2）更改makefile 3）添加lib文件4）源代碼中的新函數？好吧，讓都在一個提交，以便審閱者可以只審查一個提交，並沒有可能「依賴」的搜索。

如果對於任何原因，您的提交不符合審閱者，您和他符合最佳實現形式，並且您進行補充最終提交「由於修正了從修訂版N 「 - 減少對每個人的摩擦，清晰可見的角度進化