git 工作流程：维护功能提交的历史记录
维护 git 存储库功能版本历史记录的最佳方法是什么？
在 git 中进行分支和合并是如此简单，以至于我们一直这样做。我通常倾向于使用主题分支，仅在功能完成时才合并到主分支中。这工作得很好，但经过几次迭代后，主分支的历史是一个复杂的图表，并且很难在任何时间点识别代表应用程序正确运行版本的提交。
我正在寻找有关工作流程的建议，该工作流程使我能够轻松检索最接近指定日期的存储库的工作副本（即不在开发功能过程中）。另一个有用的功能是检索代表功能存储库随时间变化的提交列表。
我意识到这可以手动完成，即检查提交日志和消息以在启动下一个功能之前找到最后一次提交，或者通过针对每个提交运行测试套件并按其过滤。这些方法在某种程度上是可靠的，但我正在寻找一种不那么随意的方法。
What is the best way to maintain a history of functioning versions of your git repository?
It's so easy to branch and merge in git that we do it all the time. I've generally taken to using topic branches, only merging into master when a feature is complete. This works fine, but after several iterations the history of your master branch is a convoluted graph and it becomes very difficult to identify commits that represent a correctly functioning version of your application at any point in time.
I'm looking for advice on a workflow that enables me to easily retrieve a working (i.e. not in the middle of developing a feature) copy of my repo closest to a specified date. Another useful feature of this would be retrieving a list of commits that represent a functioning repository changing over time.
I realize this could be done manually i.e. examine the commit log and messages to find the last commit right before the next feature was started, or by running the test suite against each commit and filter by that. Those methods would be somewhat reliable, but I'm looking for a less haphazard way of doing it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为最好的解决方案（长期）是调整您的工作流程，以保持主分支清除中间“检查点”提交。 Benjamin Sandofsky 详细介绍了一个工作流程，该工作流程似乎最接近 Git 的设计方式。
文章要点：
预期的工作流程是：
I think the best solution (long-term) would be to adapt your workflow, to keep your master branch clean of intermediate 'checkpoint' commits. Benjamin Sandofsky details a workflow that appears to stay closest to the way Git was designed.
The gist of the article:
The intended workflow is:
您可以使用 git log --first-parent master 来查看 master 的历史记录，仅跟踪每个提交的第一个父级。这意味着当遇到合并时，仅遵循第一个父级（应该是 master 上的上一个提交），而忽略第二个父级（主题分支上的最后一个提交）。对于您的工作流程，这可能主要包括合并。重要的一点是，只要在 master 上进行的任何提交（或合并）都被视为功能版本，那么此日志中的每个提交都是功能版本。
You can use
git log --first-parent masterto see a history of master, following only the first parent of each commit. This means that when a merge is encountered, only the first parent (which should be the previous commit on master) is followed, and the second parent (the last commit on the topic branch) is ignored. With your workflow, this will likely consist of mostly merges. The important point is, as long as any commit (or merge) made on master is considered a functioning version, then every single commit in this log is a functioning version.我非常高兴听到您使用功能分支 - 加油:)
之后，有两种方法可以保持事物整洁，其中一种方法可以帮助您的大脑更好地工作。
1) 对于您正在积极工作的每个分支，创建一个本地分支。您想要这样做是因为您希望能够重新调整其他人正在做的事情。如果没有变基，您将拥有一堆代表合并的提交，这些提交实际上不会向历史记录添加任何内容。您可以对远程分支进行变基，但是不鼓励这样做，因为变基会重写历史，并且如果两个人同时执行此操作 - 它会变得很麻烦并且很难遵循。在项目的早期，我通常只是在
master的基础上工作。因此，我创建了一个不跟踪任何内容的master_local（git 分支 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）
I am super glad to hear you using feature branches - go you :)
After that, there are two ways to keep things tidy, and one thing that just helps your brain work better.
1) For each branch you are actively working on, make a local branch. You want to do this because you want to be able to rebase what everyone else is doing. Without the rebase you'll have a bunch of commits representing merges that really don't add anything to the history. You can rebase the branch which is remote, however this is discouraged as rebasing rewrites history, and should two people do it at the same time - it gets hairy and really hard to follow. Early on in projects I usually just work off
master. So I create amaster_localwhich does not track anything (git branch master_local). When people make changes I want or need (git pull), while havingmaster_localchecked out, just rebase (git rebase master).And the tip to keep your brain working well - merge your local branch into the tracking/remote feature branch often. The longer you keep things separated the more you'll have to remember, the larger your merge will be, the more others will be complaining that you're not working, etc. ;)
2) If you have large features and many people, you'll have tons of commits per feature branch. Once these features are ready to get to master you just don't need to see all of it. And if you want to revert the feature out you don't want to revert several hundred patches. The answer to all of this is to squash your commits down to 1 single commit. This way master is a nice and short list of the features contained therein. (http://www.gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html)