git-explode 0.0.1

用例#1

此工具最明显的用例是帮助提高分支管理的“卫生”程度，以便您的每个仓库分支都紧密且清晰地针对单个逻辑主题。

例如，在功能分支的工作过程中，您可能会意识到重构现有代码的机会，并可能决定立即利用这个机会，通过将重构提交添加到功能分支的顶端。在重构过程中，您甚至可能会发现一个错误，并最终也将错误修复添加到同一个功能分支中。

因此，现在您有一个功能分支，其中包含进行重构和错误修复的提交。如果您要将此分支作为一个单独的GitHub拉取请求（或GitLab合并请求，或Gerrit更改主题）提交，那么与您分别提交三个较小的审查（一个用于错误修复，一个用于重构，一个用于新功能）相比，您的合作者将难以审查。

在这种情况下，git-explode就能发挥作用！无需手动将提交分开到主题分支中，它只需一个命令就能为你完成所有艰苦的工作。

文本与语义（非）独立性

敏锐的读者会注意到，文本独立性（由git-deps检测并用于git-explode）与语义/逻辑独立性并不相同。文本独立性意味着更改可以按任何顺序应用而不会产生冲突，但这并不是逻辑独立性的可靠指标。（这一警告也见git-deps的README。）

例如，对函数的更改以及对该函数的测试和/或文档的相应更改通常存在于不同的文件中。因此，如果这些更改在分支中作为单独的提交，则在分支上运行git-explode会将这些提交放置在不同的分支中，尽管它们在逻辑上是相关的，因为不同文件（甚至在同一文件的不同区域）的更改是文本上独立的。

所以在这种情况下，git-explode的行为可能并不完全符合我们的预期。既然人工智能是一个未解决的问题，它很可能永远也不会发展出完全可靠的行为。那么，git-explode就毫无用处吗？绝对不是！

首先，当遵守提交卫生的最佳实践时，强烈逻辑相关的更改应位于同一个提交中。所以，在上面的例子中，对函数的更改以及对该函数的测试和/或文档的相应更改都应该在同一个提交中。

其次，尽管文本独立性并不意味着逻辑独立性，但相反的情况更为常见：逻辑独立性通常意味着文本独立性。因此，虽然git-explode将逻辑相关的更改分开到不同的分支可能并不罕见，但它将逻辑上不相关的更改放在同一个分支上应该是相当罕见的。结合事实，git使合并分支比拆分它们更容易，这表明git-explode仍然有大量的节省精力的潜力。

第三，允许对完美的追求成为对好的追求的敌人通常是无益的——一个工具不必完美才有用；它只需要比没有这个工具执行同样的任务更好。

关于这些点的进一步讨论可以在git邮件列表的一个旧线程中找到。

最终，“实践是检验真理的唯一标准”，所以试试看吧！

其他用例

如上所述，最明显的用例是清理逻辑上独立的提交全部混合在一个分支中造成的混乱。然而，这里还有一些其他的用例。如果你想到了其他的，请提交它们！

安装

请参阅INSTALL.rst文件。

用法

此工具尚未文档化，但如果你运行git explode -h，用法相当直观。

开发/支持/反馈

请参阅CONTRIBUTING.rst文件。

历史

我在2016年5月首次在git邮件列表上宣布了构建此工具的意向（在2016年5月）；然而，当时我误以为我可以利用我那时正在工作的git-splice和git-transplant命令来构建它。

感谢SUSE慷慨的Hack Week政策，我有幸将其作为一个Hack Week项目进行开发。

2018年5月，我利用另一个Hack Week进行了更多的完善并发布了第一个版本。这是为了在Git London用户组的Meetup活动上展示该软件。

许可证

在GPL版本2下发布，以与git的许可证保持一致，但我对双重许可的想法持开放态度，如果存在令人信服的理由。