相关疑难解决方法(0)

如何使用Git将我最后的X提交压缩成一个提交？

我试图将2个提交合并为1,所以我从git准备好跟随"压缩提交与rebase".

我跑了

git rebase --interactive HEAD~2

在生成的编辑器中,我更改pick为squash然后保存退出,但是rebase因错误而失败

没有先前的提交,不能'挤压'

既然我的工作树已达到这种状态,我就无法恢复了.命令git rebase --interactive HEAD~2失败

交互式rebase已经开始

并git rebase --continue失败了

没有先前的提交,不能'挤压'

我目前正在努力在相当复杂的开发环境中实施git使用的准则，虽然我认为我的基础设置很好，但是特别有一个问题，我想请教一下是否有可能。这并不是一个纯粹的技术问题，而是更多关于哪个可用选项最合适。

基本上，我倾向于一个与通用的“ git flow”结构（http://nvie.com/posts/a-successful-git-branching-model/）紧密镜像的系统，但有一些例外使其能够适应我们的需求开发环境。简而言之：

• 一个项目将至少有一个“开发”和“主”分支
• “主”将包含最新的生产就绪代码
• “开发”将包含最新的合并代码
• 其他任何功能都将位于“功能/票证{number}”或“修补程序/票证{number}”分支中
• 功能分支将由'develop'组成，修补程序分支将由'master'组成
• 分支机构名称中的号码将始终与我们自己的更改/错误系统中的票证号码相对应
• 通过构建适当的分支或将其合并为“开发”功能，可以单独测试功能，也可以组合测试功能

到目前为止，它确实帮助我们简化了开发流程并防止了项目之间的冲突。引发争议的一个细节是：我们是否应该使用'--squash'选项将要素/机票分支合并回各自的原点？我有点喜欢它，我喜欢它：

• 用于开发的git日志保持整洁且可读，所有提交将仅声明原始分支名称（它告诉我们它是修补程序还是功能，以及票证编号）
• 即使清除了原始功能或修补程序分支，合并之后也不会引起混淆

也许这些原因还不够好，也许有充分的理由在这种情况下不使用'--squash'。有什么想法吗？