我有一个像这样的git仓库结构-...
我想把它转换成像这样的东西-...
将文件移动到存储库中没有任何问题。但是,即使Git可能会自动检测文件移动(因为某些文件会消失,其他一些文件会出现,并且具有完全相同的内容),但还是有专门的命令来执行此操作:
git mv <source> <destination>
文件将自动移动,并且在
git status
的报告中会显示这一操作。因此,您需要提交以记录此更改。
始终进行提交是一个好习惯,因为我们应该尽量避免在 git 存储库中重命名/移动文件,除非确实有必要。这是因为这些给定文件的历史连续性将被打破,使它们难以追溯。
每个提交都应该是独立的,即使每个提交都涉及之前的提交(或合并时的多个提交)。它们基本上是一个完全限定的文件名称列表,每个文件名称指向其各自的内容,这使您可以轻松比较任何两个提交(使用
git diff
),无论它们在图形中的位置如何。
这真的很强大,但缺点是 Git 依赖于文件名来知道要比较什么。如果提交和下一个提交之间只有少量名称更改,Git 将猜测它们实际上是哪些。但是,如果您同时引入文件更改和重命名,或者如果您重命名一个文件并创建另一个具有相同内容的文件,则 Git 将感到困惑。
通过使用
git mv
,您为 Git 提供了存储每个所需信息以帮助完成此任务的机会。此外,在一些其他工作方式不同的 SCM 中,这可能是强制性的。
然后稍后在另一种语言中添加另一个仓库
这没有什么特别之处。只需像开始时那样添加额外的内容(但不要忘记提交),但请注意 Git 无法处理
空目录。因此,您需要在 "python" 目录中至少添加一个文件。这也意味着,一旦您删除了给定目录中的最后一个文件,该目录本身也将在下次检出时自动消失。不要对此感到惊讶。
这是由于如前所述,Git 只考虑文件(即使它仍能够处理符号链接和特殊文件),并通过维护完全限定文件名称(例如 "/dirname/basename")来跟踪它们各自的位置。因此,它不能处理末端没有叶子的分支。
另外,如果您的 "javascript" 和 "python" 目录没有任何关联(它们不是同一个项目的一部分),最好将它们转换为多个独立的 git 存储库。请记住,即使其中已经有一些内容,您仍可以使用
git init
初始化新的存储库。
最后,当您达到想在较大的存储库中创建一个存储库的点时,例如在公开共享小存储库同时保留有关其的其他信息,或者在处理一个其库是一个独立项目的大型项目时,您将想要查看
git submodule
,但今天不需要。 :)
filter-branch
有一个tag-filter
参数,用于控制如何重写标签。通常情况下,--tag-filter cat
可以实现通常所需的操作(将现有标签移动到重写的树中)。您可以随意为以后的操作打上标签,但是标签始终适用于某个对象,通常是一个提交 - 而提交是所有内容的快照。出于这个(和许多其他)原因,使用git在单个仓库中存储逻辑上分离的项目是不可取的。因此,如果这些项目足够独立,需要拥有各自的发布标签系列,我建议使用两个仓库。 - Mark Adelsberger