如何在不推送所有先前的提交的情况下将当前状态和所有后续提交推送到另一个远程?

时间:2015-11-10 18:49:15

标签: git version-control

对于特定项目,为方便起见,我们会在内部存储库上工作,并定期压缩整个树并将其发送给客户端(因为他们有自己的流程,不会接受任何其他内容)

我们最终设法说服他们切换到git,计划是他们自己的存储库模仿我们的(他们希望他们自己单独的代码副本出于明显的商业原因),我们仍然git push origin因为我们否则,还会git push their-remote不时批准更改,我们必须交付。

问题是,我们不想与他们分享之前的1500次提交(部分原因是由于产生的混乱,部分是因为我们有一些漂亮...... 妥协&#34 ;非正式的"提交消息)。但是,我们希望将历史记录保留在我们的内部存储库中。

更确切地说,从稳定提交开始(我们将调用" base"),在master上,在最近的过去,我们如何确保以下内容:

  • 他们(当前为空)的存储库初始化为等同于" base"的状态,但没有所有先前的提交。
  • 然后我们可以在" base"之上提交增量更改,并将这些更改推送到我们或他们的遥控器。
  • 我们的遥控器仍然包含完整的历史记录(非要求)

请注意:

  • 他们不会做出任何自己的承诺。这实际上是git-as-a-versioning-tool而不是协作工具。
  • 我们不能发布"发布"分支或其他什么,整个观点是,他们也可以在各个分支之间查看和切换,具体取决于他们想要的特定功能集/他们在实施破坏向后兼容性的新更改方面的进展。

我们尝试了--squash--depth 1rebase等的各种组合无济于事。但是我读的越多,我就越认为我们对git的运作方式存在根本的误解。

PS: 一个显而易见的解决方案是从头开始重新启动这两个存储库(复制所有文件,启动两个新存储库,粘贴它们,然后推送"初始提交"到两个遥控器,并从那里工作),但是我们想保留历史(而不是用大锤完全破坏我们的环境)。

2 个答案:

答案 0 :(得分:0)

git reset --soft commit_hash

git commit -m"下一版本发布"

git push -f origin their_branch

确保您使用的提交哈希是您的第一个初始提交,以摆脱所有提交消息。

答案 1 :(得分:0)

当您推送到远程分支时,它会查找从您推送的提交中可以访问的所有提交以及当前未驻留在远程数据库中的提交,并推送它们。这是必要的。

这就是git的工作方式。如果你有COMMIT而不是COMMIT的父母,那么你的回购无效。 git的行为将是未定义的。如果您在提交中git log指向不存在的父母,会发生什么?它应该爆炸。我很确定你要求的东西是不可能的。我认为你必须从一个扎根于BASE的新回购开始。 (保持你的旧人 - 在冰上 - 为子孙后代。)

你甚至无法通过手动将BASE的父母设置为遥控器上的[]来欺骗git。一旦你尝试这样做,BASE的SHA1将在遥控器上改变,两个repos将不再有共同的祖先。