重写未发布的历史记录有什么缺点？

我在想，特别是在开发过程中“失败的历史”的缺点是什么。一个着名的例子当然是git rebase -i/git merge --squash，但在“我想在将主要更改提交到主线之前清理我的提交历史记录”下的described here也是什么。重写未发布的历史记录有什么缺点？

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

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

来源

2012-06-10 user1447278

考虑改写你的问题来“重写未发表的历史”。重写人们可能已经建立分支机构等的事情有更多的缺点，这在你的情况下似乎并不相关。 – ThiefMaster

考虑一下：

* (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

第一个是的feature-branch一个（--no-FF）合并成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

分支历史中的相关内容仍然是明显的，其余的是压扁。

来源

2012-06-10 16:37:18 ellotheth

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

来源

2012-06-10 16:25:25 KingCrunch

除了管理生产质量代码之外，您还可以将git视为全产品全局无限延展撤消。 “未发表的历史”可能包括拼写错误，没有出现的实验，只是因为您当时在那里并且可能晚些时候会分裂出来的次要无关修复，哪些不是。我从来没有理解过对撤销的不满。

将您的重写与您改写的内容进行比较。如果新版本更好地满足您的需求，那就更好了。如果原版中的某些内容符合新版本的需求，那么这是一个缺点。特别是对于呆在你自己的回购中的未发布的东西，你可以随心所欲地处理这些东西。

来源

2012-06-10 16:26:35 jthill

重写未发布的历史记录有什么缺点？

回答

相关问题