如果GIT不跟蹤文件重命名，我們如何避免在合併中丟失這些更改？

在我們的應用程序中，我們經常需要重命名發佈分支上的文件/軟件包，然後將此更改（以及其他許多文件）合併到主幹中。一個很大的問題是許多SCM解決方案（我們目前是SVN）不會跟蹤文件重命名。當我們將產品的發佈分支合併回主幹時，很容易失去這些更改，因爲SCM沒有足夠的智能來知道MyOriginalFileName和MyRenamedFileName是相同的文件/類/ etc。如果GIT不跟蹤文件重命名，我們如何避免在合併中丟失這些更改？

在我看來，我們可能會做錯事，這將是處理這個GIT方式？

來源

2009-12-11 benstpierre

我相信Git可以跟蹤這個。

例如，我創建了一個測試git倉庫，我在裏面添加名爲test.txt一個文件，並提交它。

然後我重命名了該文件並提交了更改。

這裏是git的日誌我的承諾：

[master cf5c827] test 
1 files changed, 0 insertions(+), 0 deletions(-) 
rename test.txt => test_renamed.txt (100%)

我的建議是使用git-svn創建從你的svn庫一個Git倉庫。然後你可以玩它，看看它是否滿足你的需求

來源

2009-12-11 19:18:31

我不熟悉SVN，所以我不知道你的問題是什麼，但Git似乎做得很好重命名。

做一個重命名後，你必須確保你重新添加文件到git的指數，否則會認爲你只是刪除，而不是將其改名爲舊文件。

如果重命名文件，並做一些修改;也許你也重命名了一個#include文件。當你提交，你會得到這樣的消息：

rename: MyOriginalFilename -> MyRenamedFileName (99%)

的百分比是指如何類似於原始文件中的新一個，所以它甚至沒有要的是內容的精確副本文件。

來源

2009-12-11 19:20:42 jonescb

的Git其實並不跟蹤文件作爲一個文件，但跟蹤的樹形結構裏面的內容。不同之處在於，即使將塊從一個文件移動到另一個文件時，git也會自動識別並相應地應用合併 - 無需手動交互。

當然，當移動的塊重命名的文件全部這就像一個魅力的時候是大和獨特的不夠好，但尤其是這樣做纔有效。

來源

2009-12-11 19:26:37 johannes

Git不會使用重命名跟蹤，但它使用基於啓發式相似命名檢測。這意味着Git會比較/檢查已更改的文件，並決定有關重命名，以及哪些文件應該在解析合併期間匹配。實際上它工作得很好。

請注意，由於重命名檢測算法，如果您使用太簡單的測試用例，它不能工作;但在真正的合併中，它應該運作良好。

來源

2009-12-12 00:10:05

如果GIT不跟蹤文件重命名，我們如何避免在合併中丟失這些更改？

回答

相關問題