签入应该是小步骤还是完整功能？
版本控制的两种用途似乎决定了不同的签入样式。
以分发为中心：变更集通常会反映完整的功能。一般来说，这些签到的规模会更大。这种风格对用户/维护人员更加友好。
以回滚为中心：变更集将是单独的小步骤，因此历史记录可以像非常强大的撤消一样发挥作用。一般来说，这些签到的规模会较小。这种风格对开发人员更加友好。
当我处理一些顽固的代码/错误时，我喜欢使用我的版本控制作为真正强大的撤消。这样，我就不会害怕做出巨大的改变，只是为了尝试一个可能的解决方案。然而，这似乎给了我一个支离破碎的文件历史记录，其中有很多“好吧，这不起作用”的签入。
相反，如果我尝试让我的变更集反映完整的功能，我就会放弃使用版本控制软件进行实验。然而，用户/维护人员更容易弄清楚代码是如何演变的。这对于代码审查、管理多个分支等有很大的优势。
那么开发人员该怎么办呢？签入小步骤还是完成功能？
Two uses of version control seem to dictate different checkin styles.
distribution centric: changesets will generally reflect a complete feature. In general these checkins will be larger. This style is more user/maintainer friendly.
rollback centric: changesets will be individual small steps so the history can function like an incredibly powerful undo. In general these checkins will be smaller. This style is more developer friendly.
I like to use my version control as really powerful undo while while I banging away at some stubborn code/bug. In this way I'm not afraid to make drastic changes just to try out a possible solution. However, this seems to give me a fragmented file history with lots of "well that didn't work" checkins.
If instead I try to have my changeset reflect complete features I loose the use of my version control software for experimentation. However, it is much easier for user/maintainers to figure out how the code is evolving. Which has great advantages for code reviews, managing multiple branches, etc.
So what's a developer to do? Checkin small steps or complete features?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
可以两全其美，特别是使用
git和其他 DVCS，让您可以选择要发布的历史记录。这是一个简单的工作流程来说明这一点。您的项目有 master 和 release 分支。开发人员各自维护自己的 develop 分支，但他们不会推送这些分支。
您使用开发来完成日常工作。此处显示的是小型提交，代表项目状态随时间的增量进展。您可以创建 topic-* 分支来处理跨越几天或主要重构的较长功能。您非常频繁地开发，也许每小时几次。这就像在您正在编辑的文档中点击“保存”。
当您有一些适合下一个版本的提交时，您可以将相关提交合并到版本。 release 现在有一堆单独的提交，这些提交是有选择地从您的 develop 分支中获取的。当你到达一个好的停止点时，你承诺释放。这通常是一天几次。
当版本准备就绪时，您的首席开发人员会将自上次合并到master以来的所有提交压缩为出现在<上的单个合并提交em>大师。然后，使用发布标识符（例如，v.1.0.4）标记此提交。这种情况很少发生，可能是迭代一次或每隔几周一次。
在这里，你可以鱼与熊掌兼得。在发布之前，您可以回滚不应该发生的更改或您不想进入版本的更改，并且一次可以执行一项操作。对开发者友好！但用户也得到了他们想要的东西：在 master 上进行了大规模的承诺，代表了自上次版本以来发生的更改。
It's possible to get the best of both worlds, especially with
gitand other DVCSs that let you be selective about which history to publish. Here's a simple workflow that illustrates this.Your project has master and release branches. Developers each maintain their own develop branches that they don't push.
You use develop to do your day-to-day work. Bite-sized commits appear here, representing incremental advances in the state of the project over time. You might make topic-* branches for working on longer features that span more than a few days or major refactorings. You commit to develop very frequently, perhaps several times an hour. It's like hitting "Save" in a document that you're editing.
When you have some commits that are suitable for the next release, you merge the relevant commits to release. release now has a bunch of individual commits that have selectively been taken from your develop branch. You commit to release whenever you reach a good stopping point. That's usually a few times a day.
When the release is ready to go, your lead developer squashes all the commits since the last merge to master into a single merge commit that appears on master. Then you tag this commit with the release identifier (e.g., v.1.0.4). This happens infrequently, perhaps once an iteration or every few weeks.
Here, you get to have your cake and eat it too. Prior to releasing, you can rollback changes that shouldn't have happened or that you don't want to go into the release, and you can do it one at a time. Developer-friendly! But users get what they want, too: big, globby commits on master that represent what's changed since the last release.
DVCS 系统的美妙之处在于您可以同时拥有两者，因为在 DVCS 中，与 CVCS 不同，发布与提交是正交的。在 CVCS 中，每个提交都会自动发布，但在 DVCS 中，提交仅在被推送时才会发布。推送。
因此，提交小步骤，但仅发布工作功能。
如果你担心污染你的历史，那么你可以重写它。您可能听说过重写历史是邪恶的，但事实并非如此：只有重写已发布的历史才是邪恶的，但同样，由于发布和提交是不同的，您可以在发布之前重写未发布的历史。
例如，这就是 Linux 开发的工作原理。 Linus Torvalds 非常关心保持历史的干净。在一封关于 Git 的早期电子邮件中，他说发布的历史记录应该看起来不像您实际开发它，而是您将如何开发它，如果你无所不知，能预见未来，而且从不犯任何错误。
现在，Linux 有点特殊：它以每 11 分钟 1 次提交的速度进行提交，每天 24 小时、每周 7 天、每年 365 天，包括晚上、周末、节假日和自然灾害。而且这个比率还在增加。想象一下，如果每一个拼写错误和脑残都会导致一次提交，那么会有多少次提交。
但是开发人员自己在他们的私人存储库中可以随意提交。
The beauty of DVCS systems is that you can have both, because in a DVCS unlike a CVCS, publishing is orthogonal to committing. In a CVCS, every commit is automatically published, but it in a DVCS, commits are only published when they are pushed.
So, commit small steps, but only publish working features.
If you are worried about polluting your history, then you can rewrite it. You might have heard that rewriting history is evil, but that is not true: only rewriting published history is evil, but again, since publishing and committing are different, you can rewrite your unpublished history before publishing it.
This is how Linux development works, for example. Linus Torvalds is very concerned with keeping the history clean. In one of the very early e-mails about Git, he said that the published history should look not like you actually developed it, but how you would have developed it, if you were omniscient, could see into the future and never made any mistakes.
Now, Linux is a little bit special: it has commits going in at a rate of 1 commit every 11 minutes for 24 hours a day, 7 days a week, 365 days a year, including nights, weekends, holidays and natural disasters. And that rate is still increasing. Just imagine how much more commits there would be if every single typo and brainfart would result in a commit, too.
But the developers themselves in their private repositories commit however often they want.
小步骤。它被称为修订控制，而不是发布控制是有原因的：）
随心所欲地提交。不要退缩。在“正在进行的”分支上提交代码永远不应该产生负面后果。期望承诺不“破坏构建”的开发商店正在滥用 RCS。同样，为提交赋予任何含义都是危险的策略，因为它与修订控制的目的相冲突。相反，意义应该归因于标签、分支、克隆、存储或您的 RCS 所称的任何内容。这些东西具有旨在传达目的的元数据（可能最小到名称）。修订只是您修改内容的历史记录。
您最不想做的就是制定一项政策来阻止开发人员出于任何原因提交其代码。
Small steps. There's a reason it's called revision control, and not release control :)
Commit as often as you like. Don't hold back. There should never be negative consequences to committing code on an "in progress" branch. Development shops that expect commits not to "break the build" are misusing the RCS. Likewise, ascribing any meaning whatsoever to a commit is dangerous policy, simply because it conflicts with the purpose of revision control. Meaning should instead be ascribed to tags, branches, clones, stashes, or whatever your RCS calls them. These things have meta data (perhaps as minimal as a name) designed to convey the purpose. Revisions are simply a history of what you modified.
The last thing you want to do is institute a policy to discourage developers from committing their code, for any reason.
我的建议是创建一个分支甚至单独的存储库以用于实验目的。然后，一旦该功能完成，您就可以将分支中的代码合并回代码主干中。希望这能让您两全其美。
My recommendation would be to create a branch or even separate repository for experimentation purposes. Then, once the feature is complete, you could then merge the code from the branch back into the main trunk of code. Hopefully, that would allow you to have the best of both worlds.
我真正喜欢 Git 的一件事是你的开发中的存储库。环境是你的仓库。它是维护者存储库的副本。你可以自由地对该存储库做任何你想做的事情，并且除非你推出一些疯狂的历史记录，否则你不会惹恼维护者。
到那时，请尽可能多地利用分支和合并来帮助您的开发和实验。只将您最喜欢的更改推送到上游。如果需要，Git 甚至使您能够将提交历史记录压缩为更少的更改集，这样您就可以将执行的一系列提交推送到单个提交中。
这种灵活性极大地增强了您的个人工作流程以及同事制定的政策。
One thing I really like about Git is that the repo in your dev. environment is YOUR repo. It's a copy of the maintainer's repo. You're free to do what ever you want to that repo and you won't tick off the maintainer unless you push up some crazy histories.
To that point, use branching and merging to your advantage as much as you can to aid in your development and experimentation. Only push the changes you are most comfortable with upstream. Git even gives you the ability to squash your commit history into fewer change sets if needed so you can push up a series of commits you performed into a single commit.
The flexibility is extremely empowering to your personal work flow as well as the policies your colleagues have in place.
小步骤真的很棒。您始终可以将它们捆绑到另一个存储库中的更大步骤中。要执行相反的操作，您必须“重写历史记录”，这可以在某些系统（特别是 git）中完成，但它并没有像您希望的那样得到很好的支持。
我喜欢小步骤的另一个原因是，我的同事可以轻松地看到我做了什么。如果我工作三到四个小时，对我来说，列出六次提交通常会更明智，这样我的同事可以看到相关的差异。 （我很感激他们向我提供了同样的礼貌。）
最后，小步骤可以减少你发生冲突的可能性，或者当你发生冲突时，冲突会变得更小。
即使在多个分支上单独工作时，我也会使用小步骤。
总结：对于日常工作流程，小步骤有很多优点。如果您想要一个以分发为中心的工作流程，请创建一个存储库和一个仅用于分发的分支，然后您可以按照您想要的方式在那里设置您的大步骤。
Small steps are really great. You can always bundle them into larger steps in another repo. To do the opposite you have to "rewrite history" which can be done in some systems (notably git), but it's not as well supported as you might like.
Another reason I like small steps is so my colleagues can easily see what I've done. If I work for three or four hours it's often much more sensible for me to reel off half a dozen commits so that my colleagues can see the relevant diffs. (And I appreciate it that they extend me the same courtesy.)
Finally, small steps make it less likely that you'll have conflicts, or that when you do, they'll be smaller.
I use small steps even when working alone, on multiple branches.
Summary: For daily workflow, small steps have many advantages. If you want a distribution-centric workflow, create a repo and a branch just for distribution, and you can set up your big steps there exactly the way you want them.
大多数时候，我可以遵循以下经验法则——一次检查有意义的最小数量（并且仍然有用或改进）。我发现这可以帮助我更好地规划我的工作，这有几个好处，包括（但不限于）......
，有时需要创建一个分支，然后当工作完成后，将其合并回主线。然而，一旦在分支机构进行操作，我仍然尝试遵循该规则，因为它确实会自动放弃所有这些好处。
希望这有帮助。
Most of the time I can get away with the following rule of thumb -- check in the smallest amount at a time that makes sense (and still be useful or an improvement). I find this helps me better plan out my work, which has several benefits including (but not limited to) ...
There are times however when it is necessary to create a branch and then when the work is done, merge that back into the mainline. However, once operating on the branch, I still try to follow the rule as it does automagically waive all those benefits away.
Hope this helps.