相关疑难解决方法(0)

来自mercurial,我使用分支来组织功能.当然,我也想在我的历史中看到这种工作流程.

我使用git开始了我的新项目并完成了我的第一个功能.合并该功能时,我意识到git使用快进,即如果可能,它会将我的更改直接应用到主分支并忘记我的分支.

因此,思考未来:我是唯一一个从事这个项目的人.如果我使用git的默认方法(快进合并),我的历史将导致一个巨大的主分支.没有人知道我为每个功能使用了一个单独的分支,因为最后我只有那个巨大的主分支.这看起来不专业吗？

通过这种推理,我不想要快进合并,也不知道为什么它是默认的.这有什么好处的？

我在这里遇到了一个问题:我28s在Git中有一个特定于问题的分支,我在一般develop分支中合并.事实证明我做得太快了,所以我使用git-revert来撤消合并.然而,现在是合并的时候28s了develop,但是git-merge命令看到了原始的合并,并且愉快地宣布一切都很好并且分支已经合并.现在我该怎么做？创建'还原'还原"28s - >开发""提交？似乎不是一个很好的方法,但我现在无法想象任何其他.

树结构是什么样的:

我们的团队使用Github Pull Requests来管理我们的工作流程,就像这里描述的一样.在手动查看接受的Pull请求时,我们偶尔需要还原该合并,因为它尚未准备好部署到我们的生产服务器.

但是,如果开发人员再次尝试发出Pull Request,则无法识别这些更改已恢复,并且发现提交已在主分支中.它只包括自恢复以来最近的提交,但我们真正想要的是重新引入所有已经恢复的提交,以及他们的新工作.换句话说,我们喜欢重新发布原始Pull请求的方法.

由于Github不支持此功能(即,既不恢复合并,也不撤消/重新发布原始拉取请求),我目前正在还原恢复的合并.这感觉不对.

我可以用什么方法在git中实现相同的目标？(或Github,如果可能的话)