在历史记录中创建中间提交

Question

我的任务是将我们的集中式VCS解决方案复制到git存储库中。我的计划是使用Jenkins管道吸收CVCS中的提交，从git中提取最新的提交，然后将这些更改提交到git上并推送。

目标是捕获每次提交，为此，我将使用CVCS中的web钩子将相关信息传递给管道，以标识历史中的特定提交。为了这个问题的目的，假设所有的开发都是在一个没有分支的无休止的行中完成的。

我关心的是web钩子调用的异步特性。如果我已经提交了1000同步到git，那么提交1001和1002几乎同时出现，Jenkins管道可能在1001之前运行1002。这本身并不是一个大问题(我打算在git上包含一个文本文件，以跟踪最后一次同步的CVCS提交)，但如果我能够以更智能的方式处理1001而不是丢弃它，那就太好了。

在git历史中有什么方法可以创建中介提交吗？类似于：

git checkout HEAD~1
git checkout -b some_temp_branch
git commit -m "This is commit 1001"
git checkout master
git merge some_temp_branch -Xtheirs         # or something?

由此产生的历史来自：

1002
 |
1000

至

1002
 |
1001
 |
1000

没有改变工作目录？

Answer 1

无论您是要转换到Git，还是希望在Git、这些工具已经存在。中创建存储库的镜像。他们有多好的发展取决于VCS。例如，git-svn开发得很好；Git可以充当Subversion的双向镜像。其他的则可以在网上找到，请查找<vcs name>2git。例如，如果您使用CVS，您会查找cvs2git或git cvsimport。

如果您的VCS还没有Git迁移工具，您可以通过将提交转换为适合git fast-import的格式来构建Git迁移工具。与其让Jenkins参与进来，不如使用普通的VCS客户端来检索最新的提交；这样就不会出现订单问题。

如果目的是要转换到Git，我建议倒置你的过程。哪种方法最好取决于您的情况，但通常最好使用Git作为领导者存储库，使用旧的VCS作为跟随者。Git非常灵活和强大。它可以适应您如何使用旧的VCS，但您的旧VCS不能适应Git。让Git成为跟随者限制您使用与现在相同的版本控制；转换的意义是什么？

如果Git是领导者，那么Git可以像您习惯的那样以集中的方式执行任务。确保只提交到master，并始终将本地提交放在使用git pull --rebase的主服务器端，然后再推送。同时，您可以探索Git的新特性；例如，特征分支。如果有必要保留旧的VCS，则通过镜像创建一个只读镜像，将master分支提交到旧的VCS中。

Answer 2

值得注意的是，无论您如何做到这一点，您所得到的并不是插入的提交。

如果你重新基地-无论你怎么做-你得到一个新的分支，以一个新的提交结束。新分支可以重用旧分支的名称(导致明显的问题，我们所说的“分支”到底是什么意思？)，但是新提交链将具有与原始提交链不同的新哈希ID。

也就是说，如果你有：

... <-c1000a <-c1001a   <-- master

因为您的系统认为c1001应该在c1000之后出现，现在意识到，不，应该在两者之间提交，您可以创建一个新的c1001b

... <-c1000a <-c1001a   <-- master
            \
             c1001b

但是现在你必须把c1001a的东西复制到c1002b上

... <-c1000a <-c1001a   <-- master
            \
             c1001b <- c1002b

现在您可以将名称master指向c1002b，“忘记”c1001a：

... <-c1000a <-c1001a
            \
             c1001b <- c1002b   <-- master

被遗忘的提交持续存在(并且是有效的)，只要Git在某个地方记住它的散列ID (通常是在重新触发器条目中，用于30+天，但在没有宽限期的--bare存储库服务器上除外)。如果其他Git已经抢占了c1001a，那么其他Git会保留它，并可能将其与c1002b-or合并--不管master的最新提示是什么--因为稍后，如果它们都被命名为master，您可能希望c1001a合并进来。(你真的不知道，但吉特不知道。)

如果合并，就会在最后得到一个合并提交。将提交添加到新的临时分支：

             c1001a   <-- master
            /
... <-c1000a
            \
             c1001b   <-- temporary

然后使用git checkout master; git merge -s ours temporary从c1001a保留源树。

             c1001a
            /      \
... <-c1000a        c1002a   <-- master
            \      /
             c1001b   <-- temporary

删除临时名称将给出最终结果：

             c1001a
            /      \
... <-c1000a        c1002a   <-- master
            \      /
             c1001b

这不会给任何其他Git存储库带来任何心痛，因为您并没有故意抛出一个错误的提交，而是支持一个新的和改进的版本(其他Git可能会将其带回)。相反，您只是添加了提交，所有的Git都理解其他Git在任何时候要做的事情。

合并方法的缺点是，这可能不是正确的历史。