我一直在使用Mercurial但想要快速演示Git.
什么是Git等价物:
hg init . # start a project in the current directory
hg addremove # look for any added or deleted files
hg commit -m "comment" # commit any uncomitted changes
hg status # what have i changed since the last commit?
ric*_*chq 104
在那里没有提到的两个之间还有一些其他的问题.当我走另一条路(git - > hg)时,我的博客文章中列出了这个列表.
Hg .hgignore,语法:glob与git的.gitignore行为相同.
Git .git/config,〜/ .gitconfig,使用git-config修改值
Hg .hg/hgrc,〜/ .hgrc,使用hg help -c config
Git git commit -v
Hg hg diff | 减; hg commit
Git gitk
Hg hg view,或者来自TortoiseHg
Git git gui
Hg Mercurial不提供GUI来选择变更集,只有控制台hg record命令.
Git git rebase
Hg hg rebase.因为git rebase --interactive有hg hetedit或Mercurial Queues
Git git push URL; git remote add origin URL
Hg hg push URL; $ EDITOR .hg/hgrc; [paths]默认=网址
Git gitk,git log origin/master..HEAD
Hg hg outgoing
Git git format-patch RANGE
Hg hg email -m filename -o
Git git add.; 注意点
Hg hg add; 不需要点.
Git git checkout REVISION-KEY
Hg hg update CHANGESET
只是填补空白,Mercurial的一些最有用的命令:
Hg hg记录
Git git add -p; git commit
Hg hg inc [URL]
Git没有真正的等价物.你只能做相当于hg pull; hg log -r .:
Hg hg out URL
Git如果你知道如何,请添加.
对于合并冲突解决方案,hg resolveMercurial中的命令有一些可以更改行为的选项:
Hg hg resolve -m FILE(通过手动修复冲突问题将文件标记为已解决)
Git git add FILE
Hg hg resolve -u FILE将文件标记为未解析的
Git git reset HEAD FILE以取消暂存文件
Hg hg resolve -l(列出已解决/未解决冲突的文件)
Git git status - 干净地合并的文件会自动添加到索引中,那些没有冲突的文件
Hg hg解析FILE(合并后,尝试重新合并文件)
Git没有相应的重新合并我知道的.
Von*_*onC 48
注意:Git和Mercurial之间最大的区别之一是索引或临时区域的明确存在.
Git是唯一公开索引或临时区域概念的DistributedSCM.其他人可以实现并隐藏它,但在任何其他情况下,用户都不知道也不必处理它.
Mercurial的粗略等价物是
DirState控制工作副本状态信息以确定要包含在下一次提交中的文件.但无论如何,这个文件是自动处理的.
此外,通过在命令行上指定要提交的文件或使用,可以在提交时更具选择性RecordExtension.如果您对索引感到不舒服,那么您的转换效果会更好;-)
诀窍是,你真的需要了解完全利用Git的索引.正如2006年5月的这篇文章提醒我们的那样(现在仍然如此):
"如果你否认索引,你真的否认git本身."
现在,那篇文章包含了许多现在更易于使用的命令(所以不要太依赖它的内容;)),但总的想法仍然是:
您正在处理一项新功能,并开始对文件进行微小修改.
# working, add a few lines
$ git add myFile
# working, another minor modification
$ git add myFile
此时,您的下一次提交将在当前分支中进行2次小修改
# working, making major modification for the new features
# ... damn! I cannot commit all this in the current branch: nothing would work
$ git commit
此时仅记录添加到暂存区域(索引)的更改,而不记录工作目录中当前可见的主要更改.
$ git branch newFeature_Branch
$ git add myFile
下一次提交将记录新分支'newFrature_Branch'中的所有其他主要更改.
现在,以交互方式添加甚至拆分提交是Mercurial可用的功能,通过' hg record'命令或其他扩展:您将需要安装RecordExtension,或者CrecordExtension.
但这不是Mercurial正常工作流程的一部分.
Git将提交视为一系列" 文件内容更改",并允许您一次添加一个更改.
你应该研究这个特性及其后果:大多数Git能力(比如能够轻易地恢复合并(或者将问题一分为二,或者恢复提交),与Mercurial相反)来自"文件内容"范例.
tonfa(简介中:"Hg dev,pythonist":数字......)在评论中插入:
在索引中没有任何根本的"git-ish",如果它被认为是有价值的,hg可以使用索引,实际上
mq或者shelve已经做了一部分.
好家伙.再来一次.
首先,我不是要让一个工具看起来比另一个更好.我发现Hg很棒,很直观,有很好的支持(特别是在我的主要平台Windows上,虽然我也在Linux和Solaris8或10上工作).
该指数实际上是Linus Torvalds与VCS协同工作的前沿和中心:
Git从第1天开始使用显式索引更新,甚至在第一次合并之前也是如此.这就是我一直以来的工作方式.我往往有脏树,在我的树一些随机的补丁,我不希望提交,因为它只是为下一个版本一个Makefile更新
现在,索引的组合(这不是仅在Git中看到的概念)和 "内容为王"的范例使得它非常独特并且"git-ish":
git是一个内容跟踪器,除非与其内容相关联,否则文件名没有任何意义.因此,git add filename唯一合理的行为是将文件的内容及其名称添加到索引中.
Git的索引基本上被定义为
- 足以容纳总" 内容树"(这包括所有的元数据:文件名,模式,文件内容是所有部分!"内容",他们都对自己的意义)
- 额外的"统计"信息,以允许明显和微不足道(但非常重要!)文件系统比较优化.
所以,你真的应该看到指数是内容.
内容不是"文件名"或"文件内容"作为单独的部分.你真的不能把两者分开.
文件名本身没有意义(它们也必须有文件内容),文件内容本身也同样没有意义(你必须知道如何到达它).我想说的是git从根本上不允许你看到没有内容的文件名.整个概念都是疯狂的,无效.它与"现实"无关.
从FAQ中,主要优点是:
git diff,并用git add或验证每个小步骤git add -u.git diff --base,git diff --ours,git diff --theirs.git commit --amend如果在此期间未修改索引,则仅允许修改日志消息我个人认为这种行为不应该是默认的,你希望人们提交经过测试或至少编译过的东西
虽然你是正确的(关于"测试或编译"部分),但是Git允许你进行分支和合并(挑选或重新定位)的方式允许你在临时的私有分支中随意提交(仅推送)远程"备份"存储库),同时在公共分支上重做那些"丑陋的提交",并进行所有正确的测试.
Dus*_*tin 12
水银:
hg init . # start a project in the current directory
hg addremove # look for any added or deleted files
hg commit -m "comment" # commit any uncomitted changes
hg status # what have i changed since the last commit?
Git等价物:
git init
git add -A
git commit -am "comment" # -a is not necessary along with the above add -A
git status