Question

我想知道在开发过程中“失去历史”的缺点是什么。一个着名的例子当然是git rebase -i / git merge --squash，但在“我希望在将更改提交到主线之前清理我的提交历史记录”下的described here是什么。

我可以看到导出补丁并将它们应用到另一个分支会丢失分支的“历史”，但为什么该分支及其提交历史在合并之后会有用呢？

有人可以详细说明为什么这些技术被认为是“脏”的？为什么只要它们可以应用于主分支，最初提交的顺序更改是否重要？

Answer 1

考虑一下：

* (master) Merge feature-branch into master
|\
| * (feature-branch) Fix a comment typo
| * Add comments
| * Add feature task 3
| * Consolidate feature tasks 1 and 2
| * Add feature task 2
| * Forgot a semi-colon
| * Add feature task 1
|/
* Older commit on master

VS。这样：

* (master, feature-branch) Add feature
* Older commit on master

第一个是（{no-ff）合并feature-branch到master，底部是feature-branch到master的壁球/底板。第一个是非常详细的，这将使回归测试更集中，但如果你有很多功能分支，它将变得混乱。如果你有很多功能，第二个是更清晰，但失去了分支定义。您自己的方法取决于项目的规模，团队的规模等。

就个人而言，我会使用任何其他人都会关心此提交经验法则。下游没有人关心这一点，例如我在评论中修正了一个拼写错误。在推送之前，我通常会将第一个示例变成这样的（使用rebase -i）：

* (master) Merge feature-branch into master
|\
| * (feature-branch) Add feature task 3
| * Add feature task 2
| * Add feature task 1
|/
* Older commit on master

分支历史的相关部分仍然很明显，其余部分被压扁。

Answer 2

如果你没有看到对自己的历史有任何用处，那么没有任何缺点。事实上，许多开发人员在一个单独的分支（feature/1234）中创建新功能，然后将它们合并，然后将它们重新压缩/压缩到develop - 分支上并删除功能分支。原因是，通常情况下，如果实现某个功能，通常不会对以后的每个实现步骤感兴趣，而是对整个功能部分感兴趣。但是，你应该避免压缩提交，没有任何共同点，只是因为保存提交。许多提交也没有任何缺点。

Answer 3

除了管理生产质量代码之外，您还可以将git视为整个产品全局无限可修复的撤消。＆＃34;未发表的历史记录＆＃34;可以包括拼写错误，没有完成的实验，你做的微小的无关修复，因为你当时在那里并且可能稍后拆分，什么不是。我永远不会理解对撤消感到皱眉的心态。

将您的重写与重写的内容进行比较。如果新版本更好地满足您的需求，那就更好了。如果原版中的某些内容符合新版本的需要，那么这就是一个缺点。特别是对于保留在您自己的回购中的未发表的内容，您可以根据自己的喜好进行操作。

重写未发表的历史有什么缺点？

3 个答案: