想象一下,我将所有软件都放在一个名为A1
的4GB文件夹中。想象一下,我正在跟踪A1
以及包含一些文档的另一个文件夹Foo
。
我的日常工作包括在A1
中开发我的软件,更改Foo
中的一些文件并执行一些提交。
但是,在我的开发过程中,我只更改了A1
中包含的一些文件。其他开发人员可以更改A1
中的所有文件,但他们正在使用其他版本控制系统。每隔一段时间,他们就会发布A1
的更新版本,并要求我将我的代码集成到新版本中并从那里继续开发。让我们调用其他开发人员A2
发布的文件夹。
现在的问题是我的文件夹A1
与我通过git跟踪的贡献,但现在我将使用的某个共享区域中有一个新的更新文件夹文件夹A2
。
这个问题的简单解决方案如下
git mv A1 A2
git commit
git checkout -b update_A1_A2
cp -rf MyCollegauesSharedSpace/A2 .
git add A2
git commit
git checkout master
git merge update_A1_A2
但在这种情况下,我担心我的回购会增长得非常快,因为现在历史记录中都存在A1
和A2
,每个回复都是4GB。
但是,鉴于从现在起我只对A2
开发感兴趣,只需从历史记录中取消包含A1
的所有先前提交即可。
然而,如果一方面我将摆脱所有A1
(保存然后4 GB),另一方面我也会摆脱我想要保留的文件夹Foo
。如何解决这个问题?
答案 0 :(得分:0)
为什么使用两个目录A1和A2?难道你不是在模仿git会为你做什么吗?
另外,知道你的神器是什么会很好吗?他们的补丁?完成的编译产品?您的贡献是否应该流回他们的版本控制系统,如果是,那该怎么办?
如果我在你的鞋子里,我会为他们的发展创造一个“原始”的分支,并且每次他们做新的发布时,只对这个分支进行更改。从那以后我就用我的贡献创建了一个分支,并且只在那里工作。每次他们发布新版本时,我都会将其提交给原始分支并对其进行标记。然后我将这些更改合并到我的开发分支。这让git负责跟踪文件更改,并保持大小可管理。