如果使用 Mercurial 或 Git，经常提交文件是否有好处？
似乎建议我们经常提交来跟踪我们编写的代码的中间更改......例如在使用 Mercurial 或 Git 时在 hginit.com 上。
但是，假设我们从事一个项目，并且经常提交文件。现在，出于某种原因，经理希望部分功能消失，因此我们需要进行推送，但我听说在 Mercurial 或 Git 上，无法推送单个文件或文件夹……要么提交所有内容被推或什么都没有被推。因此，我们要么必须恢复所有我们不想推送的文件，要么我们永远不应该在推送之前提交——就在提交之后，我们推送？
It seems that it is suggested we can commit often to keep track of intermediate changes of code we wrote… such as on hginit.com, when using Mercurial or Git.
However, let's say if we work on a project, and we commit files often. Now for one reason or another, the manager wants part of the feature to go out, so we need to do a push, but I heard that on Mercurial or Git, there is no way to push individual files or a folder… either everything committed gets pushed or nothing get pushed. So we either have to revert all those files we don't want to push, or we just never should commit until before we push -- right after commit, we push?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
管理此问题的最佳方法（无论您使用 Mercurial、Git
或任何其他版本控制系统）是为了确保您的工作
是在与这些“部分”相对应的分支上完成的
功能”。即使有很小的可能性，某些部分
工作需要独立于其他工作发布，它
从一开始就应该有自己的分支。
这使您可以灵活地仅推动“部分”
功能”，并且更适合“部分
功能的一部分”和其他一些“功能的一部分”都包含
对同一文件的更改。
在这里使用 Mercurial 或 Git 的好处是可以管理
这些分支是微不足道的，因此创建和使用的成本
它们（即使事实证明它们不是必需的）是最少的。
现在，你不能总是预见一切。如果你最终陷入困境
不过，在你描述的情况下，很容易逃脱
的。假设您本地有 100 个变更集（尚未在服务器上），并且您只想
推送 1 个文件的当前内容。创建一个克隆
您正在处理的存储库返回到服务器版本，复制
文件结束、提交、推送并集成回来。在水银中
这看起来像下面这样：
The best way to manage this (whether you are using Mercurial, Git
or any other revision control system) is to make sure your work
is done on branches which correspond to these "parts of
features". If there is even a small chance that some portion of
work will need to be released independently from other work, it
should have its own branch from the start.
This gives you the flexibility to push just the "part of the
feature", and is much better suited in the case where the "part
of feature" and some other "part of the feature" both contain
changes to the same file.
The nice thing about using Mercurial or Git here is that managing
these branches is trivial, so the cost to creating and using
them (even if they turn out not to be necessary) is minimal.
Now, you can't always foresee everything. If you do end up stuck
in the situation you describe, though, it's easy to get out
of. Say you had 100 changesets locally (not yet on the server) and you wanted to just
push the current contents of 1 file. Create a clone of the
repository you're working on back to the server revision, copy
the file over, commit, push, and integrate back. In Mercurial
this would look something like the following:
在分支上开发。
有一个发布分支和功能分支。当每个功能可用时将其合并。
Develop on branches.
Have a release branch and feature branches. Merge in each feature as it becomes available.
经常承诺是一个好习惯。就您而言，您似乎需要更频繁地开始标记和/或分支。
It is good practice to commit often. In your case, it seems like you need to start tagging and/or branching more often.
扩展和澄清其他人所说的话：经常承诺和灵活推动并不相互排斥。
您确实需要提前计划并做出承诺，以便能够适应。这意味着两件事：你需要确保你确实经常提交，并且你需要经常分支（如在 git 中）。如果您的提交很小，那么以后如果您需要有选择地将部分工作组合在一起，那么重新组织它们会更容易。如果您的分支组织良好，您可能已经拥有一个正是您想要推送的分支。
比较这两个：
现在，如果您想按原样发布这三个主题中的任何一个，您所要做的就是将其合并到 master 并推送！如果你想释放 topicA 的一半，并且这一半在提交 A1、A3、A4 和 A6 中处理，你所要做的就是变基 topicA 以首先放置这四个提交，将最后一个提交合并到 master 中，并推动。 topicA 的其余部分（A2 和 A5）可以继续进行进一步的工作。
（用 A1' 表示的提交，...因为使用 git，具有相同内容但不同父级的两个提交实际上是不同的提交。）
To extend and clarify what others have said: committing often and flexible pushing are not mutually exclusive.
You do want to plan ahead, and make your commits such that you'll be able to adapt. This means two things: you need to make sure you really commit often, and you need to branch (as in git) frequently. If your commits are small, it'll be easier to reorganize them later should you need to selectively group together part of your work. And if your branches are well-organized, you may already have a branch which is exactly what you want to push.
Compare these two:
Now, if you want to release any of those three topics as-is, all you have to do is merge it to master and push! If you want to release half of topicA, and that half is taken care of in commits A1, A3, A4, and A6, all you have to do is rebase topicA to place those four commits first, merge the last of them into master, and push. The remainder of topicA (A2 and A5) can hang around for further work.
(Commits denoted by A1', ... because with git, a two commits with the same contents but different parents are actually different commits.)