这是您通常使用 SVN 或 GIt 的方式吗？
在我看到的所有使用 SVN 或 Git 的教程中，他们总是显示它们更新单个文件。我可能在 1 天内处理 100 个文件，处理许多文件并且在一天结束时，只需对所有文件执行 1 次提交，而不是单独执行我修改的每个文件，这是否正常？
In all the tutorials I see of using SVN or Git, they always show them updating individual files. I may work on 100 files in 1 day, is it normal to work on many files and at the end of the day, just do 1 commit for all the files instead of doing each file individually that I modify?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
您通常希望将提交分组为逻辑相关的更改，所有这些更改都带有一条提交消息。
您应该始终提交工作代码；不要提交半完成的东西并破坏构建，这也可能会破坏那些试图通过测试旧版本来找出哪个提交引入了错误的人。每次提交都应包含一小组彼此相关的更改。
我不建议将当天的所有更改批量化为一次提交。如果您稍后需要查看历史记录，如果一整天的工作都塞到一个提交中，那么将很难找到您需要的更改。如果您需要恢复更改，最好可以恢复整个提交，而不必一次有选择地恢复一个文件。
当然，有时你会遇到一个复杂的改变，需要一整天的时间才能完成；在这种情况下，如果这都是一个逻辑更改，那么在一天结束时进行一次提交。合理一点，这里没有绝对的规则。
You generally want to group commits into logically related changes, all with one commit message.
You should always commit working code; don't commit something that's half done and breaks the build, which could also break someone who's trying to find out which commit introduced a bug by testing older versions. Each commit should contain a small set of changes that are all related to each other.
I wouldn't recommend batching up all of your changes for the day into one commit. If you need to look through the history later on, it will be hard to find the change you need if an entire day's work is crammed together into one commit. If you need to revert a change, it's best if you can revert an entire commit, instead of having to selectively revert a file at a time.
Of course, on some days, you will have a complicated change that takes an entire day to create; in that case, if it's all one logical change, then do one commit at the end of the day. Be reasonable, there are no absolute rules here.
我通常将其分解为工作单元。如果修改所有 100 个文件完成了一个工作单元，请在一天结束时将其全部检查一遍。但更有可能的是，您为一项任务触及 5 或 10 个文件，然后为另一项任务触及 20 个文件，依此类推。我建议对每一项任务进行签入。如果没有其他原因，您的入住记录将会更准确、更有用。
I typically break it down into units of work. If modifying all 100 files accomplished one unit of work check it all in together at the end of the day. But it's more likely that you touched 5 or 10 files for one task, then 20 files for another, etc., etc. I would recommend performing a check in for each of those. If for no other reason, your check in notes will be more accurate and more useful.
这是正常的，但有时较小的提交比仅在一天结束时提交更好。如果您正在与一个大团队合作并且仅在一天结束时提交，那么在更新时（提交之前）可能会出现冲突。
当您和您的团队也进行代码审查时，较小的提交会更好。因此，您只需提交 5、10 个文件，审阅者就会更轻松地审阅代码。如果您提交 100 个文件，审阅者将需要做更多的工作。
It's normal, but sometimes smaller commits are better than commit only at the end of day. If you are working with a big team and you commit only at the end of the day you probably will have conflicts when you update (before the commit).
Smaller commits are better when you and your team do code review too. So, you commit only 5, 10 files and the reviewer will review the code more easily. If you commit 100 files the reviewer will have much more work.
我不喜欢每天 1 次提交。这感觉更像是备份而不是源代码控制。
我建议将作为同一任务/错误修复/功能的一部分更改的文件一起提交，否则，它们应该是单独的提交。
如果某一天的所有文件都属于同一功能，那就没问题。但是，如果修改的文件用于多个不相关的任务，那么这会使以后的恢复和合并变得更加复杂。
I don't like 1 commit a day. That feels more like a backup than source control.
I recommend committing files together that were changed as part of the same task/bugfix/feature, otherwise, they should be separate commits.
If all of your files for a particular day are part of the same feature, then that's fine. If, however, the files modified are for multiple, unrelated tasks, then this makes reverts and merges more complicated later on.
正如其他人提到的，最好小批量提交，每个批次都包含一个独立的更改。
但这不仅仅是为了让您的版本控制历史记录更加有用。它还可以提高您的工作质量，特别是如果您将其与详细的提交评论结合起来。
您会发现，在每次提交之前，您需要评估您所做的事情，以便编写有用的评论。这将引导您思考更改的后果，并且您可能会记住一些未测试的副作用，或者需要修复的问题。
此外，它还能让您一次专注于一项任务。如果你同时在脑子里记住几十个变化，你最终会忘记一些东西。通过单独提交更改，您将能够专注于每个更改的质量。
As others have mentioned, it's best to commit in small batches, where each batch contains a self-contained change.
But this isn't just to make your version-control history more useful. It also improves the quality of your work, especially if you combine it with detailed commit comments.
You'll find that, before each commit, you need to take stock of what you've done, in order to write a useful comment. This will lead you to think through the consequences of your change, and you'll probably remember some side-effect that you didn't test, or something that you need to fix.
In addition, it will keep you focused on one task at a time. If you're keeping dozens of changes in your head at once, you'll end up forgetting something. By committing changes individually, you'll be able to focus on the quality of each change.
（回答 Subversion。）
嗯，通常认为将一组文件作为独立的“更改”提交是理想的。例如，如果您正在开发一个网站，并向页面添加一个新图像，您的提交将类似于：
如果给定的修订版对应于单个功能、错误修复，那么它确实会使存储库的历史更有意义。或重构（等等）。有两件事需要避免：
我知道很难记住对所有更改都执行此操作，并且我因使用消息“备份杂项更改”或同样有用的消息提交了一堆不相关的内容而感到内疚。这些都是失误，一两个不会造成伤害。但很高兴看到这样的历史：“修订版 1，实现 X（修改 A 并添加 B）。修订版 2，修复错误 Y（修改 C）。修订版 3，重构 Z（修改 D 和 E 并重命名 F）至 G) 等。
(Answering for Subversion.)
Well, it's generally considered ideal to commit a group of files as a self-contained "change". E.g. if you're working on a website and you add a new image to a page, your commit would be something like:
It really does make the history of the repository more meaningful if a given revision corresponds to a single feature, bug fix, or refactoring (etc.). There are two things to avoid:
I know it's hard to remember to do this for all changes, and I have been guilty of committing a bunch of unrelated stuff with the message "backup misc changes" or something equally useful. These are lapses and one or two don't hurt. But it really is nice to see a history that says: "Revision 1, Implement X (modify A and add B). Rev 2, Fix bug Y (modify C). Rev 3, Refactor Z (modify D and E and rename F to G). Etc."
最佳实践是进行原子提交，即实现一次完整修改的提交（理想情况下，允许编译源代码树）。这通常涉及在一次提交中触及许多文件。
A best practice is to make atomic commits, that is, commits that implement one complete modification (ideally, allowing your source tree to compile). This frequently involves touching many files in a single commit.
这很正常。只需确保代码在提交之前已编译即可。该技术称为“原子提交”，AFAIR。它有很多优点：
请注意，在 VCS 的实现方式中，由于大量提交，对空间消耗几乎没有影响。
It's normal. Just make sure that the code compiles before commiting. The technique is called "atomic commits", AFAIR. It has a lot of advantages:
Note, that in the way that VCS's are implemented there's little impact on space consumption due to a large number of commits.
考虑针对不同功能/错误的单独分支
除非您编辑的所有文件都是同一功能或错误的一部分，否则您可能需要考虑针对每个错误/功能进行分支。将文件作为一个组（原子）一起提交到每个分支，直到它们完成足以合并回主干。这避免了经典的冲突，即文件对两个功能进行了修改，并且只需要立即发布其中一个功能。
svn/git 使这种风格的分支比其他一些版本控制工具更容易。
Consider separate branches for different features/bugs
Unless all the files you edit are part of the same feature or bug, you might want to consider branching for each bug/feature. Commit files together as a group (atomic) to each of those branches until they are done enough to be merged back into the trunk. This avoids the classic conflict of files having modifications in for two features and needing to release only one of them right away.
svn/git make this style of branching easier than some other version control tools.