git deps
1.0.0
git-deps是用於對GIT存儲庫中提交之間依賴關係進行自動分析的工具。這是屏幕截圖演示：
我已經寫了有關git-deps和相關工具的博客，並多次公開談論該工具：
很明顯，單個回購中的兩個git提交在某種意義上可以將彼此視為“獨立”，如果它們不更改相同的文件，或者如果他們不更改同一文件的重疊部分（s）。
相比之下，當提交更改線路時，它不僅取決於上次更改該行的提交，而且還取決於任何負責提供周圍環境行的提交，因為如果沒有該行的那些以前的版本及其上下文，則提交的diff可能不會清晰地應用（當然要根據其應用程序的應用方式）。因此，可以通過編程中的所有依賴性在“提交”變化的行上進行編程來推斷，但是對於此特定依賴性分析的用例，許多上下文行是有意義的。
因此，依賴性計算受“ fuzz”因子參數（cf patch（1））的影響，即上下文的線數被認為是通信差異所必需的。
與許多依賴關係一樣，這些依賴關係在dag（有向無環圖）中形成邊緣，其節點與提交相對應。請注意，節點只能取決於其祖先的子集。
重要的是要意識到， git-deps推斷的任何依賴圖在語義上可能是不完整的。例如，它不會在更改代碼的提交A與另一個提交b之間自動檢測依賴關係，該依賴性是更改文檔或測試以反映CONTE的代碼更改A中的A。因此， git-deps不應以盲目的信念使用。有關更多詳細信息，請參見下面的文本和語義（IN）依賴性的部分。
有時，了解該依賴圖的各個部分的性質很有用，因為它的性質會影響操作的成功或失敗，包括合併，rebase，cherry，挑選櫻桃等。請參閱USE-CASES.md文件以獲取更多詳細信息。
請參閱INSTALL.md文件。
請參閱USAGE.md文件。
敏銳的讀者會注意到， git-deps檢測到的文本獨立性與語義 /邏輯獨立性不同。文本獨立性意味著可以在任何順序上應用任何更改而不會產生衝突，但這不是邏輯獨立性的可靠指標。
例如，對功能的更改以及對該功能的測試和/或文檔的相應更改通常存在於不同的文件中。因此，如果這些更改是在分支機構內的單獨提交中，即使它們在邏輯上相關，在提交上運行git-deps也不會檢測到它們之間的任何依賴性，因為不同文件（甚至在同一文件的不同區域中）在文本上是獨立的。
因此，在這種情況下， git-deps不會確切地表現我們可能想要的方式。只要AI是一個未解決的問題，它就不可能發展出完全可靠的行為。那麼這是否意味著git-deps是沒有用的？絕對不是！
首先，當遵守提交結構的最佳實踐時，無論如何，在邏輯上與邏輯上密切相關的更改無論如何都應在同一提交中。因此，在上面的示例中，對函數的更改以及對該功能的測試和/或文檔的相應更改都應在單個提交中。 （儘管這不是唯一的有效方法；對於更高級的元歷史組合機制，請參見git-dendrify 。）
其次，儘管文本獨立性並不意味著邏輯獨立性，但預期相反的獨立性是更常見的：邏輯獨立性通常意味著文本獨立性（或以另一種方式說明，文本依賴性通常意味著邏輯依賴性）。因此，儘管git-deps無法檢測到與邏輯相關的變化之間的依賴關係可能並不少見，但它應該更罕見，它會錯誤地滲透在邏輯上無關的更改之間的依賴性。換句話說，通常期望其假否定性比其假陽性更普遍。結果，與上限相比，它在確定依賴關係的下限時可能更有用。話雖如此，需要更多的研究。
第三，讓尋求完美成為善良的敵人通常是無濟於事的 - 工具不必是完美的才能有用；它只需要比沒有工具執行相同的任務更好。
有關其中一些要點的進一步討論可以在GIT郵件列表中的舊線程中找到。
最終，“證明在布丁中”，所以請嘗試一下！
請參閱CONTRIBUTING.md文件。
請參閱HISTORY.md文件。
特別感謝Suse部分贊助該軟件的開發。還要感謝所有貢獻代碼，錯誤報告和其他反饋的人。
根據GPL版本2發布，以與git的許可一致，但是如果有令人信服的原因，我對雙重許可的想法開放。
