似乎建议我们可以经常提交以跟踪我们编写的代码的中间更改……例如在使用 Mercurial 或 Git 时在 hginit.com 上。
但是，假设我们在一个项目上工作，并且我们经常提交文件。现在出于某种原因，经理希望部分功能退出，所以我们需要进行推送，但我听说在 Mercurial 或 Git 上，无法推送单个文件或文件夹……要么所有内容都提交被推或什么都没有被推。所以我们要么必须恢复所有我们不想推送的文件，要么我们永远不应该在推送之前提交——在提交之后，我们推送？
【问题讨论】：
最好的管理方式（无论你使用 Mercurial、Git 或任何其他修订控制系统）是为了确保您的工作 在与这些“部分”相对应的分支上完成 功能”。如果有一个很小的机会， 工作需要独立于其他工作发布，它 从一开始就应该有自己的分支。
这使您可以灵活地仅推送“ 特征”，并且更适合“部分”的情况 的特征”和其他一些“特征的一部分”都包含 更改到同一个文件。
在这里使用 Mercurial 或 Git 的好处是管理 这些分支是微不足道的，因此创建和使用的成本 它们（即使它们被证明不是必需的）是最小的。
现在，你不能总是预见一切。如果你最终卡住了 不过，在你描述的情况下，很容易脱身 的。假设您在本地有 100 个变更集（尚未在服务器上）并且您只想 推送 1 个文件的当前内容。创建一个克隆 您正在处理的存储库回到服务器修订版，复制 文件结束、提交、推送和集成回来。在水银 这看起来像下面这样：
$ cd ~/project
$ hg clone http://server/project/trunk trunk-oops
$ cp trunk/shouldve-branched trunk-oops/shouldve-branched
$ cd trunk-oops; hg addrem; hg ci -m "We need to organize better!"; hg push
$ cd ../trunk; hg fetch ../trunk-oops
【讨论】：
在分支上开发。
有一个发布分支和功能分支。合并每个功能，因为它变得可用。
【讨论】：
经常提交是个好习惯。在您的情况下，您似乎需要更频繁地开始标记和/或分支。
【讨论】：
扩展和澄清其他人所说的：经常提交和灵活推送并不是相互排斥的。
您确实希望提前计划并做出承诺，以便您能够适应。这意味着两件事：您需要确保您确实经常提交，并且您需要经常分支（如在 git 中）。如果您的提交很小，如果您需要有选择地将部分工作组合在一起，那么以后重新组织它们会更容易。如果你的分支组织良好，你可能已经有了一个正是你想要推送的分支。
比较这两个：
One branch, few commits:
- A1 - B1 - C1 - B2 - A2 - B3 - C3 (master)
Many branches, many commits:
M1 - M2 (master)
/
o - A1 - A2 - A3 - A4 - A5 - A6 (topicA)
|\
| B1 - B2 - B3 - B4 - B5 - B6 - B7 (topicB)
\
C1 - C2 - C3 - C4 - C5 (topicC)
现在，如果您想按原样发布这三个主题中的任何一个，您所要做的就是将其合并到 master 并推送！如果你想释放 topicA 的一半，而那一半在提交 A1、A3、A4 和 A6 中得到处理，你所要做的就是 rebase topicA 以将这四个提交放在最前面，将它们中的最后一个合并到 master 中，和推。 topicA 的其余部分（A2 和 A5）可以继续进行。
M1 - M2 ------------- X (master)
/ /
o - A1 - A3' - A4' - A6' - A2' - A5' (topicA)
（由 A1' 表示的提交，...因为在 git 中，两个具有相同内容但不同父级的提交实际上是不同的提交。）
【讨论】：