有没有办法直接签出git的“修改的”或“未合并的路径”文件？

我知道通过以下命令签出这两个修改过的文件还有很长的路要走

git add <filename>
git reset HEAD <filename>
git checkout <filename>

---

但是，有没有一个命令可以检查所有未合并的路径？

您列出的命令序列不会生成-他们的版本。相反，它会在工作树和索引中生成-ours版本。有几种方法可以通过较少的命令和多个路径名来实现这一点

第二种方法可能是您应该使用的方法：

git checkout --ours path1 path2 ... pathN

或：

然后是相同路径的git add。请确保可以放弃他们或您对合并基础所做的更改！要特别注意哪个commit是合并的基础，这样你就知道你保留了什么，扔掉了什么

要缩短这一步，可以使用git checkout HEAD或git checkout MERGE_HEAD并跳过git add步骤；但见下文

这里需要理解的关键是，每当Git检测到冲突时，Git都会将文件的所有三个版本存储在索引中。在这种情况下，您可以访问这三个版本中的任何一个或所有版本。例如，这就是git mergetool获取它调用的基本、本地和远程版本的方式，git更一般地调用合并基础、头部或我们的版本以及其他或他们的版本

请记住，索引是Git保存每个文件副本的地方，这些文件将进入下一次提交。Git将其称为索引、暂存区域，有时也称为缓存，具体取决于Git文档中进行调用的部分。在正常操作中，任何此类文件只有一个副本。也就是说，如果您在签出的提交中有一个名为README.txt的文件，并且该文件位于可以处理的工作树中，那么在索引中也有一个相同的README.txt的副本

工作树中的副本是普通文件，格式与计算机上的任何普通文件相同。提交的副本存储在提交头中，是一种特殊的、仅限Git的格式，它不仅是压缩的，而且是完全只读的：提交的副本永远不能更改。当然，您可以使用不同版本的README.txt进行新的和不同的提交，但是您要做到这一点，首先要将新的和不同的README.txt复制到索引中

请注意，您可以随时使用git show HEAD:README.txt在HEAD commit中查看副本。类似地，您可以使用git show:README.txt在索引中查看副本，其中前导冒号是索引中文件的特殊git语法

通常，您可以通过git add README.txt将新版本复制到索引中，它只需立即获取工作树中的任何内容，并将其复制到索引/暂存区域，覆盖以前的单个副本。但是，当您在git merge、git cherry pick、git revert、git stash apply或任何其他执行合并操作（我喜欢将合并称为动词）的操作期间遇到合并冲突时，索引将承担新的角色

虽然索引通常只保存一份README.txt，但在冲突合并期间，索引最多保存三份README.txt。请记住，合并的工作原理是将您的README.txt文件版本与该文件的某个合并基础版本进行比较，然后将其README.txt版本与该合并基础版本进行比较。通过进行这两个单独的比较，Git可以找出您改变了什么，以及它们改变了什么。Git然后合并这两组更改，将这两组更改应用于文件的合并基础版本。另见

如果Git不能自己组合这两组更改，那么Git现在要做的就是在索引中使用它称之为stage slot的内容。Git最多可以存储四个版本，而不仅仅是索引中的README.txt。但是，它最多使用三个，并对它们进行编号：

暂存槽0保存未经确认的：README.txt。 暂存槽1保存合并基1:README.txt。 暂存槽2保存我们的版本2:README.txt。 暂存槽3保存了他们的版本“：3:README.txt”。 当git status（带或不带-short）显示未合并的文件时，它意味着在暂存插槽1、2和3中有条目。在这种情况下，不使用插槽零

Git将README.txt的冲突副本写入工作树，以便您可以查看冲突并自行解决，但它也将所有三个输入存储在索引中。您可以签出其中任何一个，但插槽2和插槽3有一个语法使其更简单：

git checkout --ours README.txt

从插槽2中提取，同时：

git checkout --theirs README.txt

从插槽3中提取。所有三个版本都保留在索引中，但现在工作树保存我们的头版本或它们的合并头版本

运行git add会立即获取工作树中的任何内容，即使其中仍然存在合并冲突，并将其写入插槽0，从而清除插槽1t 通过3。这使Git相信冲突已经解决

当然，您可以一次签出或添加多个文件名，因此您可以使用：

git status --porcelain | grep '^UU ' | cut -f2-

要生成所有未合并文件的列表，其短状态为UU，并使用该列表生成要提取的文件列表。此方法不太可靠，如果文件名中有有趣的字符或空格，则会失败，但仅适用于简单情况：

files=$(git status --porcelain | grep '^UU ' | cut -f2-)
git checkout --theirs $files
git add $files

删除一个步骤 为了缩短这一步，我们可以利用git签出的一个特殊事实。使用git checkout-我们的路径或git checkout-他们的路径让git以git-only格式从索引中提取一个文件，然后以正常格式到工作树，这不会改变索引本身的任何内容。但是使用git签出树ish path可以让git从提交中提取文件，而不是从索引中提取文件。当Git执行此操作时，它首先将该文件复制到索引中。只有在文件位于索引中之后，git checkout才会将文件复制到工作树中

将文件复制到索引中的副作用是删除文件的任何阶段1、2和3插槽副本，并将文件写入阶段0插槽。因此，如果以前未合并该文件，它会突然合并

请注意，如果我们处于冲突合并中，则要合并的提交的哈希ID存储在merge_HEAD中。如果我们在一个樱桃拾取的中间，我们正在挑选的承诺的散列ID在ChryyPhIkhHead。请参阅其他命令，了解它们存储哈希ID的位置

因此，即使暂存槽2中的副本来自头部提交，而暂存槽3中的副本来自MERGE_HEAD，如果我们故意将文件从头部或MERGE_HEAD提取到索引中，然后再提取到工作树中，这会将文件写入暂存槽0。其效果是在选择我们的头或其文件的合并头版本时解析合并

因此，对于没有困难名称的文件，命令：

git checkout HEAD $(git status --porcelain | grep '^UU ' | cut -f2-)

做选择的诀窍-我们的，而：

---

选择的诀窍-他们的git只合并！。同样，除非您确切知道自己在做什么，否则不要使用此选项。

您是在合并冲突的情况下提出此问题的吗？是的。冲突文件中的更改对我来说是不必要的，所以我想一次性删除它们。你想保留哪一个家长的版本？他们的。居住在起源分支的人。

git checkout HEAD $(git status --porcelain | grep '^UU ' | cut -f2-)

git checkout MERGE_HEAD $(git status --porcelain | grep '^UU ' | cut -f2-)