我很欣赏有很多关于这类事情的问题和博客文章，但是我正在寻找的小变化加上我缺乏Git的经验正在使我的努力失败，我现在有点迷失
所以，我有一个本地Git存储库，如下所示：
temp: (A)----[bunch of commits]----(Z)
temp A是存储库中的第一个提交Z是temp的提示（现在看起来像什么）A和Z之间存在大量垃圾（合并/“oops”提交，错误提交消息等）现在我想采取这个并开始一个看起来（大致）像这样的工作流程：
有3个分支：
dev 公开（推送到中央回购站）以及每个人提交的地方，使用CI，并且预计会变得像上面的temp一样充满垃圾。
在开发周期结束时（sprint，feature，...），dev被“合并”到集成中。我不对维护这里的历史感兴趣所以我想这不是一个合适的合并，我只想要一个提交dev中的所有或可能的一些更改。
执行发布时，该过程会从integration重复到master。历史记录也不重要，我希望通过integration中的更改进行一次提交。
最重要的是，这个过程应该可以轻松重复。
我想这是一个起点我可以将temp重命名为dev并从那里开始。然后我不确定如何在没有实际合并的情况下处理“合并”，这样我就可以在integration和master保持一个干净的历史记录。
我检查了merge --squash它看起来像我想要的但是当我们想从同一个分支做多个南瓜时它似乎不合适。
有人可以在这里说清楚吗？没有找到一个完整的食谱，只是在正确的方向上的一些指示。
背景
我知道实现这一目标的正确方法是使用rebase工作流程。虽然我的印象是，为了工作，每个开发人员必须对Git有一些很好的知识，并准备好处理一些混乱的情况。不幸的是，我在这里是不可能的，人们仍然使用存储库作为“检查点”。这将不得不改变，但需要时间。与此同时，我正在尝试在清洁和“脏”区域之间拆分存储库，并自己维护代码转换。
答案 0 :(得分：0)
我会使用互动式变基（git rebase -i HEAD~10）
我发现最好一个一个地进行更改并退出并在每个更改之间保存更改，或者您可能会做很多工作，如果出现错误或最终无法有效保存或合并中的问题。
您还可以在git branch, fork, fetch, merge, rebase and clone, what are the differences?
上查看有关该信息的更多信息