推荐Gitlab flow中的merge request方式
master, develop分支都是不让直接push的
master = production
develop = next release
当有新需求时，建立需求分支 feature/aaa
开发完成后创建 merge request
code review 后合并 feature/aaa 到 develop 分支
上线时合并 develop 分支到 master
发布 master 分支

对于楼主的问题可以这样
基于 feature/aaa 建立新分支 feature/bbb 完成补救工作后合并到 develop, feature/aaa 建立新分支 feature/bbb 完成补救工作后合并到 develop, master 然后上线
继续 feature/aaa 的开发工作，最后合并到 develop, feature/aaa 的开发工作，最后合并到 develop, master

可以参考 git workflow

大致就是 从 master分支checkout一个hotfixes分支。在hotfixes把补救的写好，然后分别merge到master和develop。此时就可以删除这个hotfixes分支。

然后再从develop分支开发完善你的功能，最后把develop分支merge到master上线。

或许还有更好的方法，仅供参考

雷雷

先帮楼主解决这个问题。

楼主的分支策略不用做特殊处理，按照正常的流程，结合 git 的功能即可处理的很好：

• 首先，在 develop 上开发完成的 commit 后继续提交补救性的代码，以保证 develop 的特性可以正常发布使用。这里楼主提到的“补救性的方案”其实是特性开发的一部分，不算 bugfix 。
• 之后，在测试通过后可以进入 release 流程。如果楼主本来的分支策略中有 release 分支，可以在上一步结束后就打出 release 分支，develop 继续接受新的特性提交。而这次设计的方案和临时性的补救在 release 上接受 bugfix。
• 上面其实都是正常的开发发布流程。后续的设计的开发和补救功能的删除怎么办呢？其实后续的开发其实可以看做改进或者是新特性都可以，正常开发就好。你们可以根据需要在这个改进的过程中任何的节点 revert 当初的补救提交（git revert 命令)。
• revert 补救和“原有的设计”实现后，在按照正常的发布流程发布就好了。

按照我的理解，楼主所说的“原功能”、“补救方案”这些都是正常的代码提交。楼主所困惑的应该是临时补救方案最终要被丢弃（回滚）这个问题如何处理，所以使用上面提到的 git revert 命令应该能满足楼主的预期。这样既能保证所有的对代码库的操作都可以被记录在主干（master、develop）中，也避免了复杂的分支模型等问题。

另外，不知道楼主使用的分支策略是不是 按照 @rsj217 提到的 workflow 来做的。如果 develop 是所有开发人员的主要开发分支的话，我觉得 develop 最好还是不要接受未完成的开发特性直接提交比较好。日常的开发工作，尤其是多特性/分支并行开发的情况下，多个特性分支能避免相互之间的干扰。
回到楼主的问题上来，这个不能使用的设计方案可以继续开发，不要合并到 develop 上去。基于这个分支 checkout 一个补救特性的开发分支，测试完成后合并到 develop 进入发布流程即可。后面的 merge 和 revert 建议还是要的，非迫不得已不要违背流程做特殊处理，而且这样保留了所有的代码commit操作。

建议参考git工作流 master主分支 develop用于开发 release用于发布新版本 hotfix用于修复线上bug等紧急操作

姑且说你的补救分支是develop1，上线之后develop1和master会merge到一起变成了新的master,原功能的分支develop等成熟稳定之后merge下新master（很大可能会冲突）,把develop1的那部分删掉，测试没问题上线。有点麻烦，可能还有点笨，可是git每次merge都是向前产生了一个新的点，你要是想等develop稳定了把master回退，如果中间有其他发布了，不久丢东西了么。
或许还有更好的方法，仅供参考

如果看 A successful Git branching model 吃力，可以看 Juven Xu 的翻译 一个成功的Git分支模型

使用git-flow会对你有帮助，可以用简单的命令，帮你完成创建，完成分支。并且有规范的release,hotfix,feature工作流