git工作流程：维护功能提交的历史记录

Question

维护git仓库功能版本历史的最佳方法是什么 ？

在git中进行分支和合并非常容易，我们一直都在这样做。 我通常会使用主题分支，仅在功能完成时才合并到master。 这可以正常工作，但是经过几次迭代后，您的master分支的历史是一个复杂的图形，并且很难在任何时间点识别代表您的应用程序正常运行的版本的提交。

我正在寻找有关工作流的建议，该工作流使我能够轻松地检索到最接近指定日期的工作清单（即不在开发功能中）。 另一个有用的功能将是检索代表功能库随着时间变化的提交列表。

我意识到这可以手动完成，即检查提交日志和消息以在下一个功能启动之前找到最后一个提交，或者通过针对每个提交运行测试套件并对其进行过滤。 这些方法在某种程度上是可靠的，但我正在寻找一种不太随意的方法。

Answer 1

您可以使用git log --first-parent master来查看git log --first-parent master的历史记录，仅在每次提交的第一个父节点之后。 这意味着在遇到合并时，仅遵循第一个父对象（应该是master上的上一次提交），而第二个父对象（主题分支上的最后一个提交）将被忽略。 对于您的工作流程，这很可能主要由合并组成。 重要的一点是，只要在master上进行的任何提交（或合并）都被认为是有效版本，那么此日志中的每个单个提交都是有效版本。

Answer 2

我很高兴听到您使用功能分支-去吧:)

在那之后，有两种方法可以使事情保持整洁，一种可以帮助您的大脑更好地工作。

1）对于您正在积极工作的每个分支，请创建一个本地分支。 您之所以要这样做，是因为您希望能够重新确定其他人在做什么。 没有重新设置基准，您将有很多提交代表合并，而这些合并实际上并没有添加任何历史记录。 您可以重新设置远程分支的基准，但是不建议重新建立历史记录，并且两个人应同时执行时，这是不鼓励的-它变得冗长，而且很难遵循。 在项目初期，我通常只是master 。 所以我创建了一个master_local ，它不跟踪任何内容（git分支master_local）。 当人们做出我想要或需要的更改（git pull）时，在检出master_local同时，只需重新设置基准（git rebase master）。

以及保持大脑正常工作的技巧-经常将本地分支合并到跟踪/远程功能分支中。 您将事物分开的时间越长，您将需要记住的越多，合并将越大，其他人将抱怨您不工作，等等；）

2）如果您拥有大型功能并且有很多人，那么每个功能分支将拥有大量的提交。 一旦准备好掌握这些功能，您就无需全部查看。 而且，如果您想还原该功能，则不想还原数百个补丁。 所有这些的答案是将您的提交压缩到1次单次提交。 这种方式，母版是其中包含的功能很好的简短清单。 （http://www.gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html）

Answer 3

我认为最好的解决方案（长期）是适应您的工作流程，使主分支保持中间的“检查点”提交不受影响。 本杰明·桑多夫斯基（Benjamin Sandofsky）详细介绍了工作流程 ， 该工作流程似乎最接近Git的设计方式。

文章的要旨：

考虑两类分支：公共分支和私有分支。

公共分支机构是该项目的权威历史。 在公共分支中，每个提交都应简洁明了，原子化，并具有记录良好的提交消息。 它应尽可能线性。 它应该是不变的。 公共分支包括主分支和发布分支。 私人分支机构适合您自己。 解决问题时，这是您的便条纸。

无用创可贴，断裂等分线和怪异之谜都是您使用螺丝刀锤子的症状。

绝对不要使用香草合并将私有分支直接合并到公共分支。 首先，使用诸如重置，变基，压缩合并和提交修改之类的工具清理分支。 如果您将公开历史视为原始记录，那么快速合并不仅是安全的，而且是可取的。 它们使修订历史保持线性，更易于遵循。

将公共历史视为一成不变，原子化且易于遵循。 将私人历史视为一次性和可延展的。

预期的工作流程是：

1. 从公共分支创建一个私有分支。
2. 定期将您的工作提交到此私人分支。
3. 一旦代码完美，请清理其历史记录。
4. 将清理后的分支合并回公共分支。