Git元数据 - 有没有办法添加独立于每个分支的git元数据？

Question

最终目标：我想拥有由Git跟踪的文件，但这些文件对于所有分支都是相同的版本。如果你gitignore文件，所有分支都是相同的，但不幸的是没有跟踪。当我运行git push之类的时候，我需要这些文件在repos等之间传递。

例如，.git文件夹中的数据通常是git-ignored。我想在我的仓库中添加一些数据，以便数据独立于所有分支，但仍然出现在所有分支中，当您克隆仓库时，数据会显示出来。

这可能吗？例如，如果.git目录看起来像：

.git/
  branches/
  hooks/
  objects/
  config
  HEAD
  index

我在考虑添加一个文件夹：

.git/
  .oresoftware/

并将我的数据放在那里，其中数据独立于所有分支。

我认为这不会起作用，因为.git repo中的数据并未真正被跟踪。我正在寻找由git跟踪的东西，但对于所有分支都是一样的......

更新：在阅读了答案并思考了一段时间之后，我想也许如果我用新文件修改初始提交，那么它可以神奇地工作，但当然不是Git如何工作，每次提交都是一个完整的快照，所以改变事后的历史承诺不会改变新的承诺。

Answer 1

好的，我想我现在理解你的查询了。基本上，你需要在可见的文件夹中添加数据，以便git跟踪它，即其中一个分支中的git add <data>和merge这个分支到master，然后与master（git fetch origin master && git merge origin master）同步其他两个分支。在这种特殊情况下，由于您在git中添加了一个新文件/文件夹，因此您不会遇到合并冲突。最后，您的数据将在所有分支机构中提供。编辑（基于另一个用户的评论）：git cherry-pick <commit-hash>是另一种可以将特定提交应用于分支的方式。

Answer 2

... .git文件夹中的数据通常是git-ignored。

这不仅仅是典型的，它对于Git的安全模型是必要的。

（在过去，Git有一些错误，你可以创建名为.GIT/whatever的文件，然后他们会进入存储库，然后在Windows和MacOS上的结帐时存在于.git/whatever中，因为这些系统默认忽略大小写：一个名为.GIT/foo的文件实际上是由于.git/foo存在于此时创建为.git。此错误已在现代Git中得到纠正。）

我想在我的仓库中添加一些数据，以便数据独立于所有分支，但仍然出现在所有分支中，当您克隆仓库时，数据会显示出来。

这可能吗？

不 - 但还有其他方法可以得到你想要的东西。

克隆存储库等效于以下步骤：

• 创建一个空目录（或使用现有目录）：mkdir path。
• 在那里创建一个新的空Git存储库：cd path && git init。
• 为URL添加一个名为origin的遥控器：git remote add origin url。
• 从那个遥控器获取所有东西：git fetch origin。
• 通过git checkout：git checkout branch创建一个分支，其中branch通常是根据在前面的git fetch步骤中创建的远程跟踪名称创建的。

有许多历史特点，如果出现问题还会出现问题，所以上述情况并不完美。它还省略了可选的git config步骤。最后选择的分支是你的-b论证中的分支。如果你的-b参数命名一个标签而不是一个分支，Git只会检查一个分离的HEAD而不创建任何分支。如果你没有给出-b参数，Git使用来自远程的指令来确定要创建的分支。默认值，也就是通常的结果，是master，创建为指向与origin/master相同的提交。

一旦存储库中有一个分支或一些分支，那些分支 - 更确切地说，那些名称，如master和develop等 - 由拥有该存储库的任何人拥有。他们可以随心所欲地做任何事情;作为他们克隆的存储库的所有者，您无法阻止它们。你不能让他们在他们的分支机构中显示一个文件。当然我们可以说关于整个存储库，所以这有点愚蠢作为一个论点：你无法控制它们;他们将按照他们的意愿完成整个存储库。

据推测，你想要的是让他们很容易将某些内容安装到某个地方的文件中。这样做的方法是通过一些简单的名称访问内容。但是Git提供了什么名字？

好吧，在底层，Git存储的是提交，而这些提交又存储了存储blob（文件内容）的树（路径名）。任何给定提交，树或blob的实际名称是原始哈希ID，并且哈希ID是不可预测的，并且通常对人类无用或可由人访问。所以你可以告诉别人：

将哈希ID 1bdc91e282c5393c527b3902a208227c19971b84提取到.oresoftware/foo

但是（1）哈希ID是不可理解的，（2）谁想要输入所有内容？如果您有多个文件，则每个文件需要一个blob哈希ID。呸！

有一种更好的方法可以做到这一点。您可以创建一个包含名为.oresoftware/foo，.oresoftware/bar等文件的提交对象。这是一个普通的提交，可以随时提取到普通的工作树中。

现在假设您将此提交放在名为ORESOFTWARE的分支上。然后你可以告诉别人他们应该：

运行git checkout origin/ORESOFTWARE -- .oresoftware && git reset .oresoftware

诚然，这并不是真的更短，但至少没有充满难以理解的哈希ID。

git checkout将在他们的工作树中创建.oresoftware，只要他们有远程跟踪名称，git fetch（来自git clone）将创建.1 git reset .oresoftware将删除.oresoftware在其索引中创建的git checkout条目。如果在/.oresoftware/中列出.gitignore，则将忽略工作树文件。这意味着你必须在每个分支的每个提示提交中都有一个.gitignore，这样就可以方便地自动忽略目录，但这很容易做到。

最后，你可以说：而不是指导人们运行两个看似神奇的Git命令。

运行./setup.sh

这意味着您可以将两个Git命令放入一个shell脚本setup.sh中，您在每个分支提示中提供，就像在每个分支提示中提供.gitignore文件一样。此外，您甚至可以让您的软件构建过程自动运行./setup.sh，然后您不需要他们的任何特殊操作。

如果您决定更改.oresoftware中的文件，您只需要在自己的ORESOFTWARE分支上进行新的提交。这可以（也可能应该）只包含.oresoftware目录。因为构建过程使用每个构建重新提取目录，所以git fetch将为您的用户提供更新的origin/ORESOFTWARE远程跟踪名称，然后将获取更新的文件。