存储库子文件夹的Git标记

我使用Git导入SVN存储库。然后，我在存储库中创建了自己的项目作为子文件夹

我将SVN存储库与Git SVN一起使用。我的工作程序是：

git提交-am“message”

git-svn-rebase

git svn dcommit

现在我想用git tag-a RC1-m‘Release Candidate 1’标记我的项目，但我只希望我的项目得到标记

我该怎么做？你不能

在Git中，标记总是作为一个整体应用于存储库（就像提交和分支一样）。这与Subversion不同，Subversion中的标记（只是一个副本）可以应用于子树

顺便说一句：即使在Subversion中，通常也不鼓励标记子树，因为它很快就会混淆树的哪个部分被标记。我知道的大多数来源（例如，版本建议总是通过复制

trunk

来标记）

关于你的问题：

通常，单独的项目应该获得单独的Git存储库。在这个上下文中，“separate”通常意味着您可能需要单独进行分支/标记

---

如果您不这样做/不能这样做，最好的选择可能是使用一些标记前缀，并调用所有标记

myproj-1.0

，

myproj-1.1

等。

这在Git中是不可能的。Git标记是指向特定提交的指针，而Subversion标记是Subversion存储库中任何文件夹的副本。标记singl的概念Subversion中的e文件夹不能很好地保存到Git中

问题是您的初始设置与Git的分支模型不匹配。以Git友好的方式进行此操作的方法是为您的项目设置一个分支，然后在该分支上标记提交

您有两个选择：

• 使用

  git svn Tag

  在给定点标记整个存储库。有关使用此命令的说明，请运行

  git help svn

• 使用常规Subversion命令标记目录。这不需要下载Subversion工作副本，因为您只需运行

  svn copy{URL to your project on the repository}{URL to your Tag directory}

  ，但您需要安装Subversion

• 在一个全新的目录中启动Subversion存储库的新Git克隆。将项目文件夹指定为主干URL，而不是实际的主干。Git svn随后将该目录视为您的主分支，并允许您通过Subversion标记和复制它

---

当我不得不将一个非常大的项目转移到Git时，我发现自己也遇到了类似的问题。我发现团队没有正确地处理SVN，并且在他们想要的任何地方进行标记。因此，对于单个项目和文件夹都有标记，这是非常不鼓励的

如果您计划迁移到Git，您应该将其作为Git中的工作方式并保持干净。我建议您为频繁更改的项目创建单独的存储库。如果您发现您的项目依赖于其他项目，您还可以使用子模块。

TL；DR version 如果您知道树的SHA-1，那么可以标记特定的目录（aka trees），但是使用该标记做有用的事情并不容易

长话短说 Git中的每个对象都有一个唯一的SHA-1。最常见的是，SHA-1指的是提交，但也可以指blob（文件内容）和tree（目录结构和文件名/文件权限映射）。您可以在

例如，假设我在存储库中的特定目录中。我可以运行

git ls tree HEAD

以获取路径中的文件/目录列表及其SHA-1：

$git ls-tree HEAD
100644 blob ed76d466f5025ce88575770b07a65c49b281ca59    app.css
100644 blob ed58ee4a9be6f5b58e25e5b025b25e6d04549767    app.js
100644 blob e2bed82bd9554fdd89d982b37a8e0659fe82390a    controllers.js
040000 tree f888c44e16f7811ba69a245adf35c4303cb0d4e7    data
100644 blob d68aa862e4746fc9abd0132cc576a4df266b0a9d    directives.js
100644 blob df0ae0e7288617552b373d21f7796adb8fb0d1b6    index.html
040000 tree fa9c05b1bb45fb85821c7b1c27925b2618d646ac    partials
100644 blob 28e9eb6fe697cb5039d1cb093742e90b739ad6af    services.js

然后我可以标记其中一棵树（比如上面的

data

目录）：

标记现在是该SHA-1的别名，我可以在接受树的SHA-1的任何位置使用它：

$git ls-tree -rt data-1.0
100644 blob 6ab0a52a17d14cbc8e30c4bf8d060c4ff58ff971    file1.json
100644 blob e097e393fa72007b0c328d67b70ba1c571854db0    file2.json
040000 tree 39573c56941fdd2fc88747a96bf871550f4affb2    subfolder1
...    ...  ...                                         ...

要取回原来的SHA-1：

$git rev-parse data-1.0
f888c44e16f7811ba69a245adf35c4303cb0d4e7

这一切对你有什么好处？没有什么好处。但是，如果你愿意编写自己的脚本来重建树的内容，或者找到包含树的提交，那么它可能对你有用。（例如，可以针对这样的目的进行调整）

但正如其他人所说，使用Git更好地使用版本化/标记模型可能会更容易，而不是试图适应现有的模型。正如SkkJoHuri等人所提到的，如果您希望项目中有自己的版本，请考虑。

巧妙的解决方案。（尽管我不想实际使用它：-）。

$git rev-parse data-1.0
f888c44e16f7811ba69a245adf35c4303cb0d4e7