我通常使用 Tortoise SVN,但我一直在研究 Mercurial,因为它是一个分布式修订控制系统。
在这两个系统中,我正在寻找的是一种工具,它可以让我只选择文件的一部分并提交它们。如果我现在想这样做,我必须复制到文件的临时版本并只保留我想在当前版本中提交的更改,然后在提交后再次将临时版本复制到当前版本。真是太麻烦了,程序应该可以为我做到这一点。
我听说 Git 支持这一点,请让我知道这是否正确。
我通常使用 Tortoise SVN,但我一直在研究 Mercurial,因为它是一个分布式修订控制系统。
在这两个系统中,我正在寻找的是一种工具,它可以让我只选择文件的一部分并提交它们。如果我现在想这样做,我必须复制到文件的临时版本并只保留我想在当前版本中提交的更改,然后在提交后再次将临时版本复制到当前版本。真是太麻烦了,程序应该可以为我做到这一点。
我听说 Git 支持这一点,请让我知道这是否正确。
Mercurial 可以通过记录扩展来做到这一点。
它会提示您输入每个文件和每个差异块。例如:
% hg record
diff --git a/prelim.tex b/prelim.tex
2 hunks, 4 lines changed
examine changes to 'prelim.tex'? [Ynsfdaq?]
@@ -12,7 +12,7 @@
\setmonofont[Scale=0.88]{Consolas}
% missing from xunicode.sty
\DeclareUTFcomposite[\UTFencname]{x00ED}{\'}{\i}
-\else
+\else foo
\usepackage[pdftex]{graphicx}
\fi
record this change to 'prelim.tex'? [Ynsfdaq?]
@@ -1281,3 +1281,5 @@
%% Local variables:
%% mode: latex
%% End:
+
+foo
\ No newline at end of file
record this change to 'prelim.tex'? [Ynsfdaq?] n
Waiting for Emacs...
提交后,剩余的差异将被留下:
% hg di
diff --git a/prelim.tex b/prelim.tex
--- a/prelim.tex
+++ b/prelim.tex
@@ -1281,3 +1281,5 @@
%% Local variables:
%% mode: latex
%% End:
+
+foo
\ No newline at end of file
或者,您可能会发现使用 MQ(Mercurial Queues)将存储库中的各个更改分成补丁更容易。也有记录的 MQ 变体 (qrecord)。
更新:还可以尝试crecord扩展,它提供了一个curses接口来选择大块/行。
是的,git 允许你这样做。该git add
命令有一个-p
(或--patch
)选项,可让您逐个查看更改,选择要暂存的内容(您还可以细化这些块或编辑补丁)。您还可以使用交互模式来 git-add ( git add -i
) 并使用“p”选项。
这是一个交互式添加的截屏视频,它还演示了git add
.
查看 TortoiseHG,它将进行大块选择,并让您将不同的更改提交到一个文件,以进行不同的提交。
它甚至可以让您在一次提交中提交对某些文件的所有更改以及对其他文件的部分更改。
不久前我问了一个类似的问题,使用hgshelve 扩展得到的答案正是我想要的。
在进行提交之前,您可以将来自不同文件的更改(或文件中的大量更改)放在“架子”上,然后提交您想要的内容。然后您可以取消搁置您未提交的更改并继续工作。
过去几天我一直在使用它,并且非常喜欢它。非常易于可视化和使用。
Mercurial 现在为该命令提供了一个选项--interactive
(或-i
)commit
,它可以直接启用此功能。
这直接从命令行工作,因此如果您是命令行爱好者,它是完美的!
跑步
> hg commit -i
开始一个交互式会话,允许检查、编辑和记录单个更改以创建提交。
这与and命令的--patch
and--interactive
选项非常相似。git add
git commit
我建议不要这样工作。
如果您必须进行更改集,设置已准备好签入的设置 A 和尚未准备好的设置 B,您如何确定仅签入设置 A 不会破坏您的构建/测试?你可能会错过一些行,忘记不同文件中的行,或者没有意识到 A 对 B 的依赖会破坏其他人的构建。
您的提交应该是谨慎的原子更改,不会破坏您或您团队中的其他人的构建。如果您部分提交文件,您将大大增加您在不知情的情况下为其他人破坏构建的机会,直到您有一些不高兴的同事敲门。
最大的问题是,为什么你觉得有必要以这种方式工作?