1

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

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

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

4

3 回答 3

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

与这个：

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

第一个是 into 的 (--no-ff) 合并，feature-branch底部master是 on 的 squash/ feature-branchrebase 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

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

于 2012-06-10T16:37:18.743 回答
0

如果您对自己的历史没有任何用处，那就没有缺点了。事实上，许多开发人员在单独的分支 ( feature/1234) 中创建新功能，然后他们没有合并，而是将其变基/压缩到develop-branch 并删除功能分支。原因是，通常，如果你实现了一个特性，你通常不会对以后的每一个实现步骤感兴趣，而是对整个特性感兴趣。但是，您应该避免压缩提交，因为它们没有任何共同之处，只是为了保存提交。有很多提交也没有缺点。

于 2012-06-10T16:25:25.363 回答
0

除了管理生产质量的代码之外，您还可以将 git 视为整个产品的全局无限延展性撤消。“未发表的历史”可以包括拼写错误、没有成功的实验、您所做的不相关的小修复，因为您当时在那里并且可能稍后会分裂，等等。我从来不理解对撤消皱眉的心态。

将您的重写与您重写的内容进行比较。如果新版本更好地满足您的需求，那就更好了。如果原始版本中的某些内容满足新版本不满足的需求，那么这是一个缺点。特别是对于保留在您自己的存储库中的未发布内容，您可以随意处理其中的内容。

于 2012-06-10T16:26:35.040 回答