维护git存储库功能版本历史记录的最佳方法是什么？
在git中分支和合并是如此容易，我们一直这样做。我一般采用主题分支，只在功能完成时合并到主分支。这样可以正常工作，但经过几次迭代后主分支的历史记录是一个错综复杂的图，并且很难在任何时间点识别代表应用程序正常运行版本的提交。
我正在寻找有关工作流程的建议，这使我能够轻松检索最接近指定日期的我的仓库的工作（即不在开发功能的中间）。另一个有用的功能是检索一个提交列表，这些提交代表一个随时间变化的功能存储库。
我意识到这可以手动完成，即检查提交日志和消息以在下一个功能启动之前找到最后一次提交，或者通过针对每个提交运行测试套件并按此过滤。这些方法有点可靠，但我正在寻找一种不太随意的方法。
答案 0 :(得分：4)
您可以使用git log --first-parent master查看master的历史记录，仅遵循每个提交的第一个父级。这意味着当遇到合并时，仅遵循第一个父（应该是master上的先前提交），并忽略第二个父（主题分支上的最后一个提交）。使用您的工作流程，这可能主要包括合并。重要的是，只要在master上进行的任何提交（或合并）被认为是一个正常运行的版本，那么此日志中的每个提交都是一个正常运行的版本。
答案 1 :(得分：0)
我很高兴听到你使用功能分支 - 请你：）
在那之后，有两种方法可以保持整洁，有一种方法可以帮助你的大脑更好地工作。
1）对于您正在积极工作的每个分支，建立一个本地分支。你想这样做是因为你希望能够改变其他人正在做的事情。如果没有rebase，你将会有一堆代表合并的提交，这些提交实际上并没有为历史记录添加任何内容。你可以改变远程的分支，但是不鼓励因为变基会重写历史，并且两个人应该同时进行 - 它变得毛茸茸而且很难遵循。在项目的早期，我通常只是在master工作。所以我创建了一个master_local，它不跟踪任何东西（git branch master_local）。当人们进行我想要或需要的改变（git pull）时，在master_local签出时，只需要rebase（git rebase master）。
保持大脑正常工作的提示 - 经常将您的本地分支合并到跟踪/远程功能分支中。保持分离的时间越长，你必须记住的越多，你的合并就越大，抱怨你不工作的人就会越多，等等;）
2）如果你有很多功能和很多人，你会有每个功能分支的大量提交。一旦这些功能准备好掌握，您就不需要看到所有这些功能。如果你想恢复该功能，你不想恢复数百个补丁。所有这一切的答案是将提交压缩为1次提交。这样，master就是其中包含的功能的简短列表。 （http://www.gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html）
答案 2 :(得分：0)
我认为最好的解决方案（长期）将是调整您的工作流程，以保持您的主分支清洁中间'检查点'提交。 Benjamin Sandofsky details a workflow似乎与Git的设计方式最为接近。
文章的要点：
将分支分为两类：公共和私有。
公共分支机构是项目的权威历史。在公共分支中，每个提交都应该简洁，原子，并且具有记录良好的提交消息。它应该尽可能线性。它应该是不可改变的。公共分支包括主分支和发布分支。 私人分支是给自己的。在解决问题时，这是你的草稿纸。
没有ff的创可贴，破碎的二等分，以及责备谜团都是你用螺丝刀作为锤子的症状。
您永远不应该将私有分支直接合并到具有vanilla合并的公共分支中。首先，使用重置，rebase，squash合并和提交修改等工具清理分支。 如果您将公共历史视为原始的，快进合并不仅安全，而且更可取。它们使修订历史保持线性，更易于遵循。
将公共历史视为不可变的，原子的，易于遵循。将私人历史视为一次性和可塑性。
预期的工作流程为：