在ClearCase中，我们有能力创建一个标记的基线，它只包含由ClearQuest管理的特定变更请求所修改的二进制文件。作为参考，我们使用Jira来做同样的事情，带有一个定制的集成。问题是如何创建一个Git分支，它只包含由一个特定的提交哈希列表所引用的那些版本的文件，然后只将那些文件归档到基线.zip文件中。
我们公司正在从ClearCase迁移到Git。我们处理的代码不是传统的基于文本的源代码。它包含在由专有供应商软件创建的二进制对象中，通常是其他二进制文件的.zip存档。我们将二进制对象存储为Git LFS对象。由于我们处理的是二进制文件，不执行合并。我们使用LFS锁来保证对文件的单次访问并防止需要合并。我们的程序员也不使用命令行接口，如bash。对他们来说，处理“文件”的更新是 checkout 、更改、签入。2锁定、拉取、编辑、添加、提交、解锁的Git范例超出了它们的能力范围。3为了维护ClearCase checkout /签入范例，创建了许多 Package 器脚本，它们对程序员隐藏了Git的细节。这些脚本可以从Windows资源管理器上下文菜单命令中调用。
说了这么多，请不要说我们误用了Git。它是一个复杂的工具，并不适合所有的编程环境。然而，Git是目前最流行的版本控制工具。我们已经能够保留我们的程序员熟悉的所有ClearCase接口功能。
程序员不使用分支。我们只维护一个master分支。每个wrapper命令都拉入和推入到原始master分支。每个添加、删除或签入的文件都是在单独的提交下完成的。
以下步骤不是由典型的程序员执行的，而是由Git管理员执行的。
目前，我们：
1.创建并检出分支
1.为特定的提交创建一个哈希列表
1.在分支中执行git rm -rf .以清除所有内容
- 我尝试执行以下每一项操作来填充我们想要的文件/提交
- a.每个散列的校验
- B.每个散列的LFS校验
- c.创建一个带有版本字符串的标签（例如v1.0）
- 将标记推到原点
- checkout -f master to以恢复到原始状态
- 使用版本字符串执行git存档到zip文件
不管我们做什么，git归档都希望在最后一次提交时包含repo中的所有内容，这就是第3步的原因。
我们尝试了步骤6.1，只压缩包含项目的文件夹，得到的只是.zip中的Git lfs ref文件，这也是尝试步骤4 - a，B，c的原因。
看起来我们执行了很多步骤来完成一些简单的事情。有可能我们忽略了显而易见的东西吗？有人能建议一个更直接的方法吗？回想一下，最终的.zip结果必须只包含特定提交修改过的文件。
2条答案
按热度按时间2q5ifsrm1#
我们的程序员也不使用命令行界面，比如bash。对他们来说，处理一个"文件"的更新就是 checkout 、更改、签入。锁定、拉取、编辑、添加、提交、解锁的Git范例超出了他们的能力范围。为了维护ClearCase checkout /签入范例，创建了一些 Package 器脚本，这些脚本对程序员隐藏了Git的细节。
你真是滥用...
说了这么多，请不要回应我们滥用Git。
噢。没关系。继续。
程序员不使用分支。
那么为什么要使用Git呢？这个工具的所有成功都是基于分支之间完成的拉/合并请求。
对于 * 源代码 （二进制文件通常在Nexus等工件引用中发布/导出）
你好像误用了G ......（啊，对了，算了吧）
git archive希望在最后一次提交到归档时包括repo中的所有内容这就是Git仓库的本质，它是快照（提交）的集合，每个快照代表仓库当时的全部内容。
包括来自特定提交文件
提交意味着： 所有 * 文件，而不是"仅修改的文件"
我在"Single working branch with Git"中提到：
使用
git worktreecommand，您可以轻松结帐master上）参见"Export only modified and added files with folder structure in Git"
即：
如果要使用
git archiveonly：（将
a9359f9替换为您自己的提交ID）在后一种情况下，您甚至可以跳过我前面提到的额外结帐。
OP gitrdoneconfirms：
我不知道
git diff-tree --diff-filter=ACMRT选项。有了这个和一般的见解，它现在正如我预期的那样工作。qvtsj1bj2#
Randomly来到这里，“从ClearCase迁移到Git”听起来像是“git fidded成CC或反之亦然”，他的 * 迁移 * 阶段是什么？（所以我不想讨论或回答这些问题，但我仍然这样做。）“git中的基线”是我感兴趣的问题，目前我倾向于输出（存档，zip，.exe或任何东西）. CC是企业1990年。它似乎徘徊（我们也有一个项目），也许它的创造者之一“勒布朗”（=“livelong”德语）做了一个声明。然而，在你描述的情况下，实际的需求是什么？相反，它制造了麻烦，要求解决方案。从企业Angular 来看，这听起来像是管理层没有明确讨论可行性、需求和风险的东西。
答案就在这里：“看起来我们正在执行很多步骤来完成一些简单的事情。”