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

维护git存储库正常运行版本的历史记录的最佳方法是什么

在git中进行分支和合并非常容易，所以我们一直都在这样做。我通常习惯于使用主题分支，只有当一个特性完成时才合并到master中。这很好，但经过几次迭代后，主分支的历史记录是一个复杂的图，，因此很难在任何时间点识别表示应用程序正确运行版本的提交

我正在寻找一个工作流的建议，它使我能够轻松地检索最接近指定日期的一个工作（即不是在开发一个特征的中间）副本。另一个有用的特性是检索一个提交列表，该列表表示随着时间的推移正在运行的存储库

---

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

您可以使用git log--first parent master查看master的历史记录，只跟踪每个提交的第一个父级。这意味着当遇到合并时，只会遵循第一个父级（应该是主节点上的上一次提交），而忽略第二个父级（主题分支上的最后一次提交）。在您的工作流程中，这可能主要包括合并。重要的一点是，只要在master上进行的任何提交（或合并）都被视为正常运行的版本，那么此日志中的每个提交都是正常运行的版本。

我非常高兴听到您使用功能分支-go you:）

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

1） 对于您正在积极工作的每个分支，创建一个本地分支。你想这样做是因为你想重新确定其他人正在做的事情的基础。如果没有重基，您将有一堆表示合并的提交，这些提交实际上不会向历史添加任何内容。您可以重新设置远程分支的基础，但是由于重新设置基础会重写历史，因此不鼓励这样做，如果两个人同时执行此操作，则会出现问题，而且很难遵循。在项目的早期，我通常只做

master

。所以我创建了一个

master\u local

，它不跟踪任何东西（git分支master\u local）。当人们在签出

master\u local

的同时进行我想要或需要的更改（git-pull），只需重新设置基址（git-rebase-master）

保持大脑正常工作的秘诀是经常将本地分支合并到跟踪/远程功能分支中。你把事情分开的时间越长，你需要记住的事情就越多，你的合并就越大，其他人就越多地抱怨你没有工作，等等

2） 如果您有大型功能和许多人，那么每个功能分支将有大量的提交。一旦这些功能准备好掌握，你就不需要看到所有的功能了。如果你想恢复功能，你不想恢复几百个补丁。所有这些问题的答案是将您的提交压缩为一次提交。此way master是其中包含的功能的一个很好的简短列表。(http://www.gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html)我认为最好的解决方案（长期）是调整您的工作流程，保持您的主分支没有中间“检查点”提交。这似乎与Git的设计方式最为接近

文章大意：

将分支机构分为两类：公共分支机构和私人分支机构

公共分支机构是项目的权威历史。在公共分支中，每一个提交都应该简洁、原子化，并且有一个记录良好的提交消息。它应该尽可能线性。它应该是不变的。公共分支包括主分支和发布分支。 私人分支机构是给你自己的。这是你解决问题时的草稿

<没有FF创可贴、破碎的等分线和“怪怪”都是使用螺丝刀作为锤子的症状。

您不应该通过普通合并将私有分支直接合并到公共分支。首先，使用重置、重设基础、挤压合并和提交修改等工具清理分支。 如果你把你的公共历史看作是原始的，那么快速的合并不仅安全而且更可取。它们使修订历史保持线性，并且更易于遵循

将公共历史视为永恒的、原子的、易于理解的。将个人历史视为可抛弃的、可延展的

预期的工作流是：

从公用分支创建专用分支

定期把你的工作交给这个私人部门

一旦你的代码是完美的，清理它的历史

将清理后的分支合并回公共分支

---

+1用于保持主机始终工作。像gerrit这样的东西可能有助于确保这一点。似乎是部分解决方案。通常在合并时，自上次合并以来，主分支中不会有任何提交，因此根本不会有合并提交。但是这个解决方案总比没有好。在这种情况下，您可以强制执行在合并时使用

--no ff

的策略，以始终生成合并提交。那么，合并提交是否看起来像功能中所有提交的挤压？因为功能分支只是本地的，所以任何人都可以看到该功能的单个提交，这是正确的吗？@JJD-否。这是一个实际的合并。分支上的所有提交都被推送到服务器，就像其他所有操作一样。只有在实际使用git merge--squash时，合并提交才会看起来像一个挤压，w