git电子邮件流程与github流程

所以我＆＃39; Ve一直在使用GitHub流程，现在从维护者方面和贡献者方面到开源项目。我也一直在使用两侧的Git的电子邮件工作流程。在我实际开始使用它之前，使用电子邮件为git响起了很糟糕。现在我更倾向于，所以我以为我会在这里记录我的经验。

基本上相同的流量也用于Gitlab和其他较小的Git托管服务。这种流程合理地工作。在第一次拉拔请求后，它会稍微烦人，因为您实际上必须保持自己的本地分支到目前为止。

理论上，这也通过查看项目的叉子来说，在项目上工作的一些好的发现性。在实践中，这是一堆已经被误认为是像按钮的叉子按钮的人的过时的项目副本。

从维护者的角度来看，除非您的项目开始增长，否则此流程也可以正常工作。例如，当Postmarketos仍然在GitHub上时，我们遇到了合并按钮ISN＆＃39; t非常有用的问题。一旦您有合理的拉出请求，那些拉出请求的分支就会过时，这意味着它们必须在合并之前重建，或者每次更改都会在历史记录中有额外的合并提交。

在Postmarketos案例中，它决定合并犯历史上的额外噪音我们＆＃39; D喜欢避免所以我们需要rebase，并正确rebase我们必须从命令行执行它，因为GitHub可以与冲突交易。从命令行重新撤销也可以更有灵活性，挤压并具有很好的提交消息。

合并按钮在Github上使用按钮的唯一原因是因为GitHub可以＆＃39; T似乎将拉杆标记为合并，如果它是由按钮完成的。

旧工作流文档PostmarketOS在使用GitHub时可以在Wiki历史记录中读取：https://wiki.postmarkettos.org/Index.php?title= merge_workflow& amp; oldid = 3441

现在我们又搬到了Gitlab We＆＃39; re基本上处理同样的问题，我们必须在合并之前乱搞犯罪，所以我们始终强制推动到拉的作者的git叉子请求（如果他们不得不在合并请求上启用它，如果他们不得不告诉他们启用该复选框），然后最后将它们与Web UI中的按钮合并，所以Gitlab and＃39; t丢失跟踪发生的事情。

GitHub中的拉出请求的流量是制作拉出请求的原始方法。由于Git最初是为开发Linux内核的开发而设计，因此设计了内核的工作流程。内核使用邮件列表。

我通过电子邮件发送的第一个修补程序是https://git-send-email.io/io/，我需要了解如何使用电子邮件流，因为当我在我的第一个内核补丁时。这是一个令人生畏的任务，涉及三重检查所有针对Linux的补丁提交文档的一切，它描述了一个简单的16步进程。

然后在最后一步之后，电子邮件被发送出去，等待...用于回复电子邮件。

从那以后，我＆＃39; Ve对Sourcehut上托管的项目做出了贡献，其中也使用了电子邮件工作流程，现在我还在这个平台上维护了一些项目。例如百万像素。

这是使用电子邮件流将修补程序提交给项目的工作流程：

在邮件列表的网页上镜像时将评论作为电子邮件响应

修复您之前的错误，使用-v2参数再次运行git发送给发送更新的版本

作为一种维护者，如此，除非有那些＆＃39，否则＆＃39; t必须合并分支机构或rebase的东西，否则＆＃39是非常好的。补丁只是......一个补丁，它只有来自的变化作者，不是完整的git历史记录。

此外，关于上述过程的一件事是，除了接收反馈之外，它将永远不会触摸您的邮件客户端。 Git是SMTP本身，并确保您发送的电子邮件是最新的，因此维护者可以通过将电子邮件送入Git AM来直接应用更改

如果您的主要投诉是，电子邮件可怕，问题很可能不会通过电子邮件发送电子邮件，它可能是您的邮件客户端。

电子邮件工作流的其他主要问题之一是您可以＆＃39; t只看到＆＃34的完整状态;拉请求＆＃34;因为那里没有好的拉请求页面，看看＆＃39。这是我喜欢Sourcehut上的邮件列表的主要原因之一，修补程序视图修复了大多数可见性问题，例如这个简单的修补程序：https://lists.sr.ht/~martijnbraam/public-inbox/patches/ 14382

在那里，您在第一个块中看到了修补程序描述，这是在这种情况下，在Git发送电子邮件阶段中添加了任何额外的文本，因此它只显示了此修补程序的更改的摘要。

下面的是实际补丁，修补程序的主题是标题，然后显示下面的完整提交消息，如果有更多的行，那么完整的差异。此修补程序也可以使用主题的链接右直接导出为.patch文件。

最后，下面的差异是向发展分支应用此补丁的eyal的评论，并感谢作者;如果有更多的讨论，邮件列表将在此生成一个很好的线程视图。

右侧的块将显示修补程序的状态，在这种情况下应用，并提供了一些额外的工具，以获取可以使用git上午应用应用的完整拼凑的副本

我现在个人更喜欢电子邮件工作流程，它将我保存到迄今为止的分支/叉子，只有在此工作流程中只发送差异。此外，在Gitlab在Postmarketos上工作的大多数事情后，我真的很喜欢SourceHut页面加载的快速，而且我只能从补丁中获取所有信息，而无需单击选项卡在注释，diff和提交邮件之间切换加载时间之间。

还有一个很好的改进是，通过点击东西在我当地的git分支中，通过修补东西来制作浏览器中的维护者流程的一半，而不是在我的本地git分支中，它只是让我在shell中做所有事情，然后发送电子邮件返回告诉作者他们的补丁已合并。

所有人都最有可能已经习惯了将所有的评论和信息发送给他们作为通知，它＆＃39;在Gitlab / Hub的情况下，它将向您发送一个链接以继续在他们的网站和Sourcehut中继续/电子邮件流箱如果您需要继续的所有内容，而无需打开浏览器。