将工作区的更改与未提交的更改合并
我们最近刚刚从 SVN 切换到 Mercurial,但现在我们的工作流程遇到了问题。例子: 我有我所处理的存储库的本地克隆。我正在对我们的代码库进行一些高度实验性的更改,在我确定它按预期方式工作之前我不想提交这些更改,甚至在本地我也不想提交它。现在,我的同事同时做出了一些我需要的重大改进/错误修复。他将他的提交推送到我们的主存储库。问题是,我如何将他的更改合并到我的工作区,而不要求我必须提交所有更改,因为我需要他的更改来测试我自己的代码?
对于完全相同的工作流程,我们遇到的一个更日常的问题是我们在存储库中有几个配置文件。每个开发人员都会对配置文件进行一些特定于环境的小更改,但不提交更改。这几个未提交的文件阻碍我们对工作区进行任何合并,就像上面的示例一样。理想情况下,配置文件可能不应该位于存储库中,不幸的是,由于此处未命名的原因,它必须如此。
We've just recently switched over from SVN to Mercurial, but now we are running into problems with our workflow. Example:
I have my local clone of the repository which I work on. I'm making some highly experimental changes to our code base, something that I don't want to commit before I'm sure it works the way it is supposed to, I don't want to commit it even locally. Now, simultaneously, my co-worker has made some significant improvements/bug fixes which I need. He pushes his commits to our main repository. The question is, how can I merge his changes to my workspace without the requirement that I have to commit all my changes, since I need his changes to test my own code?
A more day-to-day problem we have with the exact same workflow is where we have a couple of configuration files which are in the repository. Each developer makes a couple of small environment specific changes to the configuration files, but do not commit the changes. These couple of uncommitted files hinders us from making any merges to our workspace, just like with the example above. Ideally, the configuration files probably shouldn't be in the repository, unfortunately, that's just how it has to be for here unnamed reasons.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
如果您知道未提交的更改不会与您正在创建的合并提交发生冲突 - 那么您可以执行以下操作...
1) 搁置未提交的更改
2) 进行拉取和合并
3) 取消搁置未提交的更改
搁置有效地存储了您的 更改未提交的更改会被保存为 diff (相对于您上次提交的),然后回滚本地工作区中的这些文件。然后取消搁置,然后应用该差异,恢复未提交的更改。
TortoiseHg 等工具具有内置架子。
If you know your uncommitted changes will not collide with the merge commit that you are creating - then you can do the following...
1) Shelve the uncommitted changes
2) Do the pull and merge
3) Unshelve the uncommitted changes
Shelf effectively stores your uncommitted changes away as into diff (relative to your last commit) then rolls back those files in your local workspace. Then un-shelving then applies that diff, bringing back your uncommitted changes.
Tools such as TortoiseHg have shelf built in.
如果您不想克隆,可以按照以下方式进行。
If you don't want to clone, you can do it the following way.
正如您所发现的,有两种操作可以使一个人的更改可供其他人(或两侧的许多人)使用。
其中有拉动,它从存储库的其他克隆中获取更改并将它们放入您的克隆中。
还有推送,它从存储库中获取更改并将它们放入另一个克隆中。
就您而言,您的同事已将其更改推送到我认为是您的存储库的中央主人中。
完成此操作后,您可以将最新更改拉入您的存储库,并将它们合并到您的分支中。这会将您的同事所做的任何错误修复或更改合并到您的实验代码中。
这使您可以自由地了解项目中其他同事的开发情况,并且不必在准备好(甚至根本不需要)之前发布您的实验代码。
因此,只要您远离 Push 命令,您就可以“安全。
当然,这也假设没有人直接从您的存储库克隆中提取,如果他们这样做,那么他们当然会得到您的实验性更改,但听起来您并没有以这种方式设置它(并且它也极不可能。)
至于配置文件,执行此操作的典型方法是仅将主文件模板提交到存储库中,并使用不同的名称(即额外的扩展名 .template 或类似名称),然后将真实配置文件的名称放入忽略过滤器中。
然后,每个开发人员都必须制作自己的模板副本、重命名并以他们想要的任何方式更改它,而无需冒将数据库连接字符串、密码或本地路径提交到存储库的风险。
如果需要,请提供一个脚本,以帮助开发人员制作真正的配置文件(如果该文件又长又复杂)。
There are two operations, as you've discovered, that makes changes from one person available to someone else (or many, on either side.)
There's pulling, which takes changes from some other clone of the repository and puts them into your clone.
There's pushing, which takes changes from your repository and puts them into another clone.
In your case, your coworker has pushed his changes into what I assume is your central master of the repository.
After he has done this, you can pull the latest changes down into your repository, and merge them into your branch. This will incorporate any bugfixes or changes your coworker did into your experimental code.
This gives you the freedom of staying current on other coworkers development in your project, and not having to release your experimental code until it is ready (or even at all.)
So, as long as you stay away from the Push command, you're safe.
Of course, this also assumes nobody is pulling directly from your clone of the repository, if they do that, then of course they will get your experimental changes, but it doesn't sound like you've set it up this way (and it is highly unlikely as well.)
As for the configuration files, the typical way to do this is that you only commit a master file template into the repository, with a different name (ie. an extra extension .template or similar), and then place the name of the real configuration file into the ignore filter.
Each developer then has to make his or her own copy of the template, rename it, and change it in any way they want, without the risk of committing database connection strings, passwords, or local paths, to the repository.
If necessary, provide a script that will help the developer make the real configuration file if it is long and complex.
关于您的实验性更改,您应该提交它们。经常。
只需将它们提交到不推送的克隆中即可。 您只需从其他存储库中提取并合并您需要的任何更新。
至于配置文件,不要提交它们。
提交模板文件,脚本能够从模板生成完整的配置文件。
这样,开发人员将仅使用自己的私有值修改“私有”(即未提交)配置文件。
Regarding your experimental changes, you should commit them. Often.
Simply you commit them in a clone you don't push. You only pull to merge whatever updates you need from other repos.
As for config files, don't commit them.
Commit template files, and script able to generate complete config files from the template.
That way, developers will only modify "private" (i.e. not committed) config files with their own private values.