我是git的新手，我从一个长期运行的项目中获得了大量的每周tar包。每个tarball平均有几百个文件。我正在寻找一种git策略，允许我将每个tarball的扩展内容添加到新的git存储库，从版本1.001开始，然后通过1.650版本。截至项目的这个阶段，99.5％的tarball（n）只是版本（n-1）的副本 - 换句话说，是git的完美候选者。期望的最终结果是在过程结束时只剩下主分支。
我认为我知道git足够“手动”做到这一点。据我了解，不存在合并冲突的可能性，因为在添加和提交下一个版本之前没有机会更改主服务器。 shell脚本是我的第一个猜测，但我不确定当bash在branch_n-1中执行时git checkout branch_n被处理时bash会喜欢它。为了这个项目的目的，主机环境是Ubuntu 10.4，可用资源是8千兆RAM，500千兆磁盘空间和4个CPU处理器3.ghz。
我不需要其他人来解决问题，但我可以在正确的方向上轻推一下git专家如何接近它。任何“做过那样”的人的建议都会受到赞赏。
布袋
PS：我查看了网站建议的“相关问题”，发现没有相关内容。
答案 0 :(得分：8)
查看$GIT_SRC_DIR/contrib/fast-import/import-tars.perl
答案 1 :(得分：3)
关于这个评论：
我不确定当bash在branch_n-1中执行时git checkout branch_n被处理时bash会有多喜欢
您是否担心两个操作同时运行并相互进入？除非您故意并行运行操作，否则这不应该是一个问题。
假设tarball遵循线性演化，那么分支就不应该进入。
这个过程应该相当简单：
git init untar ball _n_ git add --all .; git commit（带有适当的旗帜）git tag -a v1.001 -m "Version 1.001." rm -rf *（处理历史记录中的删除;当然，您希望保留完整的.git）答案 2 :(得分：2)
在这种情况下我会做什么，因为你有最终'标记版本'的tarball：
git add . git commit -a -m 'version foo' 在你的情况下，没有必要创建分支，因为你的所有tarball都是不同的连续版本;每次迭代都会覆盖前一次迭代。
答案 3 :(得分：1)
如果没有完全在那里，你应该简单地说：
git add -A git commit -m "archive n" 这个想法不是检查branch_n + 1，而是保持在同一个分支中，在同一个git repo的同一个分支中一个接一个地提交每个tar内容。
如果您真的有两个并发进程，那么您可以：
git clone第一个git repo git branch -b a_new_branch以确保您在自己的分支中隔离该并行进程，以便在完成后能够将其推回到第一个回购。答案 4 :(得分：0)
看看git-weave。你向它提供一个包含所有扩展 tarball 的目录以及一个 log 文件，其中包含它们之间的序列和连接（它处理分支）和提交消息，它由此创建一个 git 存储库。
对于大约 600 个 tarball，这看起来是一项艰巨的任务，您可能需要编写脚本来拼凑 log 文件。