如果使用Mercurial或Git，经常提交文件是否好？

似乎建议我们可以经常跟踪我们编写的代码的中间更改......例如在使用Mercurial或Git时在hginit.com上。如果使用Mercurial或Git，经常提交文件是否好？

但是，让我们假设我们是在一个项目上工作，而且我们经常提交文件。现在出于某种原因，管理员希望部分功能外出，因此我们需要进行推送，但是我听说在Mercurial或Git上，无法推送单个文件或文件夹......要么所有提交的内容被推或没有推动。所以我们要么必须恢复所有那些我们不想推送的文件，要么在我们推送之前我们永远不应该提交 - 在提交之后，我们会推送？

来源

2010-06-10 太極者無極而生

来管理这个（无论您是使用水银，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

来源

2010-06-10 19:00:34

，然后命令rmdir卡车接力？在PC上，上次我是“hg clone”和“hg update”，它就像500MB，所以如果我执行上面的步骤（2）（hg克隆），即使在PC上也不会是非常大的数据？（只要确保不要执行“hg update”，否则它将提取500MB数据？） – 2010-06-10 19:15:09

如果空间问题（或者即使不是这样），请在本地克隆。 Mercurial将创建硬链接，因此额外的空间不会被消耗。 hg clone -rSERVER_REVISION_HASH trunk trunk-oops – 2010-06-10 19:21:29

这是关于克隆的一切吗？我知道Mercurial与git并不相同，但是您肯定可以创建另一个分支，cherry-pick/rebase（或者hg analog）来获得您想要的并推送它（然后类似地照顾原始分支，但是您需要）。 – Cascabel 2010-06-11 00:09:47

在分支机构上开发。

有一个发布分支和功能分支。在每个功能可用时合并。

来源

2010-06-10 18:50:59

这是一个很好的做法，经常提交。就你而言，你似乎需要更频繁地开始标记和/或分支。

来源

2010-06-10 18:52:54 zdav

扩展和澄清一下其他人所说：常犯和灵活的推并不是相互排斥的。

您确实想提前计划，并进行提交，以便您能够适应。这意味着两件事：你需要确保你确实经常提交，并且你需要经常分支（如在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)

现在，如果你想释放其中的任何三个主题原样，所有你所要做的就是把它合并掌握和推动！如果你想释放一半的topicA，并且在提交A1，A3，A4和A6时需要处理这一半，那么你需要做的就是重新设置topicA，将这四个提交放在第一位，将最后一个合并到master中，并推动。 topicA（A2和A5）的其余部分可以继续进行下一步工作。

M1 - M2 ------------- X (master) 
/     /
o - A1 - A3' - A4' - A6' - A2' - A5' (topicA)

（提交由A1' 表示......因为git的，一两次提交内容相同，但不同的父母实际上是不同的提交。）

来源

2010-06-11 00:24:41 Cascabel

如果使用Mercurial或Git，经常提交文件是否好？

回答

相关问题