SVN变更列表的Git等价性？

我只是好奇，如果Git有类似Subversions变更列表的功能，我发现它在运行时非常方便，我知道我可以运行这样的功能：

cat 'changelistfileimade' | xargs git update

但是我很好奇是否也有一个内置的方法？

我从未使用过自己，但是如果我理解正确，它允许您将文件分组到变更列表中，然后单独提交这些变更列表。（对吗？）

我不认为Git真的需要这样的特性。您已经可以独立地转移（

git add

）每个文件或其部分（

git add-p

）并提交这些文件。您可以为每个变更列表创建分支，然后合并/重新设置这些分支的基础。或者您可以创建多个提交，然后使用交互式rebase（

git-rebase-i

）对其重新排序

您只需使用

git show changelistbranch

，而不是

svn diff--changelist something

您不必推动那些本地/临时分支机构。没有人需要看到它们，直到你认为它们已经准备好被释放到野外。

您甚至可以为“变更列表分支”命名名称空间：

git branch changelist/name\u\u您的变更列表

，然后将所有变更列表按前缀分组

---

我遗漏了什么吗？

我在谷歌上搜索了更多关于这个的信息，我想我已经找到了一个替代我在上面的评论中提到的用例的方法。所讨论的命令是

git update index——假设未更改
。Git help对此有如下说明：

--[否-]假设不变

指定这些标志后，不会更新为路径记录的对象名称。相反，这些选项设置
取消设置路径的“假定未更改”位。当“假定未更改”位打开时，Git停止检查工作状态
树文件进行可能的修改，因此您需要手动取消设置位，以便在更改工作树时通知Git
文件当在具有非常慢的lstat（2）系统调用的文件系统上处理大型项目时，这有时很有用
（例如cifs）

此选项还可用作粗略的文件级机制，以忽略跟踪文件中未提交的更改（类似于
gitignore对未跟踪文件的作用）。如果Git需要在索引中修改此文件，它将失败（正常）
e、 g.在提交中合并时；因此，如果假定的未跟踪文件在上游更改，则需要处理
手动设置情况

我在上找到了对选项的解释，其中包括以下内容：

显然，这其中有很多警告。如果您
git直接添加该文件，它将被添加到索引中。在上合并带有此标志的提交将导致合并正常失败，因此您可以手动处理它

但这对我来说只是一半的战斗。下一步是知道你忽略了什么（并希望记住为什么）。这是由Abe Voelker就一个恰当命名的问题提供的。只需使用代码段编辑
.gitconfig
文件即可

[alias]
    ignored = !git ls-files -v | grep "^[[:lower:]]"

如果文件中已经存在
[alias]
位，请不要添加该位。现在，
git-ignored
会告诉你这样的事情：

h configs/environment/local.php
h configs/logging/log4php.xml

您可以通过以下行使用
ignore
和
unignore
的别名更进一步：

    ignore = update-index --assume-unchanged
    unignore = update-index --no-assume-unchanged

@克尼蒂，我想如果我没记错的话，最新的成绩是1.5分。它们很好，因为您可以将产品部件分配到单独的列表中，并在时间紧迫时无需太多麻烦地进行更新。使用svn变更列表来准备提交就像在git中有多个暂存区域（这些区域不存在）。@BHF:git仍然允许您在更改级别上工作，而不是在文件级别上工作。我觉得这个好得多。有了rebase和local提交的强大功能，您不需要多个暂存区域。我希望有这个功能。我在SVN中使用它的主要目的是在本地保留更改，而不必担心其他人会被这些更改打扰，也不必担心这些更改会意外出现在生产中。这在配置文件中非常常见。如果您更改了分支，SVN变更列表本质上会缓存您的更改
git stash
提供了其中一些功能，但它不是自动的。但在Git中，我必须小心进行阶段性更改；无法方便地
git添加。
。TortoiseSVN甚至在提交变更列表中附带了ignore，这在这个应用中非常有效。幸运的是IntelliJ IDEA也为git内置了这个特性。如果git不支持它，那么IDEA本身似乎可以跟踪哪些文件在哪个变更列表中。没有什么东西像是
git update
。
svn-update
的等价物是
git-fetch
+
git-merge
/
git-rebase
（但与可能破坏工作副本状态的
svn-update
相比，它是非破坏性的）。简而言之：对于每个svn变更列表，您都会创建一个（本地）git分支。变更列表只是svn中没有本地分支的一种变通方法。更正：变更列表也是一种在不覆盖存储库中的文件的情况下维护本地修改的方法。我在配置文件中保留了一些变更列表，如本地数据库连接字符串、开发资源路径、资源URI以及分支的实验性更改。这些东西在部署时具有特定的值，但在开发环境中使用它们时会有所不同。不幸的是，这只适用于新文件。如果您对已经添加到git中的文件进行了更改，则假定unchanged无效。还有另一个标志称为skip worktree，但是，如果使用它，则不能再使用checkout切换到不同的分支。对我来说，这是一场表演。总之，我必须使用zip/unzip来保存/恢复我不希望提交的所有更改。这真的很痛苦。看见