229 积分 美国密歇根州 Ravi 是一名无人机行业的软件工程师。他曾致力于解决各种问题，例如无人机传感器软件集成、DevOps、数字信号处理以及将机器学习应用于各种问题。他一直在为自己的工作和爱好寻找新的和有趣的软件工具。他最喜欢的主题领域包括 Python、C#、Unity 和容器。他喜欢写作，并与开源社区分享他一路学到的知识精华。 思想开放 作者 贡献者俱乐部
撰写的评论
感谢您提出一些重要的讨论要点！
本文中讨论的工作流程，特别是关于变基和压缩的内容，适用于每个开发人员在单独的功能分支上工作并具有功能分支的强制推送权限的用例。在您的 Git 用法中，当一个功能分支有多个贡献者时，我同意压缩和变基的这种组合将不适用。
我同意与现有代码的重构或其他重大代码更改相关的提交通常不应与为该功能添加的新文件相关的提交压缩在一起。
通常，每个功能分支在压缩后都会产生少量提交。 其中一些将是由于您提到的事情（例如，重构现有代码）。 一两个提交将是由于将与新功能相关的新文件相关的提交压缩在一起的结果。
我不确定您关于拉取请求是单个提交的评论。 可以为功能分支中的少量提交提交拉取请求。 然后，批准者可以执行合并提交，其中将包括多个拉取请求提交，以及表示从功能分支合并拉取请求的附加提交。
我同意您的担忧，即我们不应过度概括等等。 事实上，解释特定技术的目的应该是让新团队成员了解情况的一部分，并理解可能需要一些经验才能理解这些概念。 （例如，我认为人们必须在错误修复期间与一些 Git 日志作斗争，才能真正体会到拥有良好、有序的 Git 提交历史的价值。）我想在这种情况下，我只是将“最佳实践”视为此常见用例的良好工作流程与 Git。 此工作流程当然不适用于每个基于 Git 的项目。
是的，那是个好主意！ 谢谢。