Git将特征分支的历史改变为一个新的分支？
其他人可以更好地改写这个问题，但我想做的是：
我一直在做一个长期的主要工作——重构分支B。我一直在定期合并主分支，现在分支B已经领先主分支大约200次提交。我现在准备发送一个拉请求，但是我想清理一下我的提交历史。基本上，我想把我所有的200次提交压缩成3次提交:
- 提交1=所有被删除的文件
- 提交2=所有新添加的文件
- 提交3=所有其他内容，即所有移动/编辑的文件
而且，为了不搞砸，我想在我自己的分支B的另一个分支上重写历史，并将该分支作为我的拉取请求发送。
在git中实现这一点的最简单方法是什么？
共有2个答案
< code > git rebase-interactive (如专业Git书籍中所述)并不实用，因为它允许挑选或压缩提交(而不是提交的一部分)
另一种方法可能是生成一个巨大的补丁（如git formate-察觉源/master），然后解析该文件，生成3个补丁文件：
- 一个包含所有删除的内容
- 一个包含所有附加功能
- 其余的
然后，您可以从发起的提交分支B创建一个分支（请参阅“参考Git分支开始提交”），并应用这三个补丁。
假设您要合并到< code>master:
>
创建并签出新分支：
git checkout -b going-to-squash
重设母版的基础
git rebase --squash master
重置到主分支
git reset master
现在，您的整个被挤压的分支将处于未提交状态。
立即创建新提交。
我将为这一步使用gui，但它在命令行上完全可行。
-
让我们来看一个简单的分支新建与分支合并的例子，实际工作中你可能会用到类似的工作流。 你将经历如下步骤： 开发某个网站。 为实现某个新的需求，创建一个分支。 在这个分支上开展工作。 正在此时，你突然接到一个电话说有个很严重的问题需要紧急修补。 你将按照如下方式来处理： 切换到你的线上分支（production branch）。 为这个紧急任务新建一个分支，并在其中修复它。 在测试通过之后，切换回线上
-
在 Git 中整合来自不同分支的修改主要有两种方法：merge 以及 rebase。 在本节中我们将学习什么是“变基”，怎样使用“变基”，并将展示该操作的惊艳之处，以及指出在何种情况下你应避免使用它。 变基的基本操作 请回顾之前在 分支的合并 中的一个例子，你会看到开发任务分叉到两个不同分支，又各自提交了更新。 Figure 35. 分叉的提交历史 之前介绍过，整合分支最容易的方法是 merge
-
我是《回到未来》的粉丝，偶尔会做梦，梦见穿梭到未来拿回一本2000-2050体育年鉴。操作Git可以体验到穿梭时空的感觉，因为Git像极了一个时光机器，不但允许你在历史中穿梭，而且能够改变历史。 在本章的最开始，介绍两种最简单和最常用的历史变更操作——“悔棋”操作，就是对刚刚进行的一次或几次提交进行修补。对于跳跃式的历史记录的变更，即仅对过去某一个或某几个提交作出改变，会在“回到未来”小节详细介绍
-
像个白痴一样，我做了超出当前分支范围的更改。 我更改了5个文件 我想提交我的basics.rb文件到我的分支，基础，和我的horse.rb文件到一个新的分支，马。我已经做了git签出-b马，所有的文件显示。我还没有提交。我该怎么办？
-
如上图，我想实现图上的效果，合并dev分支上历史连续提交的几个commit为一个到master主分支上，但是并不合并到最新 我知道直接合并分支到最新的提交为一个commit是以下代码 但是不想合并到最新应该如何操作呢？ 可能还会有下面的需求 将上面不同的连续几个分别合并成几个commit到master上
-
同生活中的许多伟大事物一样，Git 诞生于一个极富纷争大举创新的年代。 Linux 内核开源项目有着为数众广的参与者。 绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上(1991－2002年间)。 到 2002 年，整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。 到了 2005 年，开发 BitKeeper 的商业公司同 Linux