我只需要一份冲突文件列表。

还有什么比:

git ls-files -u  | cut -f 2 | sort -u

or:

git ls-files -u  | awk '{print $4}' | sort | uniq

我想我可以为此设置一个方便的别名,但我想知道专业人士是如何做到的。我会用它来写shell循环,比如自动解决冲突等等。也许可以通过插入mergetool.cmd来替换这个循环?


试图回答我的问题:

不,似乎没有比问题中的方法更简单的方法了,开箱即用。

在键入太多次之后,只是将较短的一个粘贴到一个名为“git-conflicts”的可执行文件中,让git可以访问,现在我可以: git冲突来获得我想要的列表。

更新:正如Richard所建议的,你可以设置一个git别名,作为可执行文件的替代

git config --global alias.conflicts '!git ls-files -u | cut -f 2 | sort -u'

通过别名使用可执行文件的一个优点是,您可以与团队成员共享该脚本(在repo的bin dir部分)。


如果您尝试提交,并且存在冲突,那么git将为您提供当前未解决的冲突列表……但不是普通的列表。这通常是您在交互工作时想要的,因为当您解决冲突时,列表会变得更短。


Git的状态会在有冲突的文件旁边显示“已修改”,而不是“已修改”或“新文件”等


git status --short | grep "^UU "

使用git diff,带name-only只显示名称,diff-filter=U只包括'Unmerged'文件(可选地,相对于当前工作目录显示路径)。

git diff --name-only --diff-filter=U --relative

这里有一个万无一失的方法:

grep -H -r "<<<<<<< HEAD" /path/to/project/dir

我一直只使用git状态。

可以在最后添加awk来获得文件名吗

git status -s | grep ^U | awk '{print $2}'


查尔斯·贝利的回答略有变化,提供了更多信息:

git diff --name-only --diff-filter=U | xargs git status

也许这已经添加到Git中,但尚未解析的文件在状态消息(Git状态)中列出,如下所示:

#
# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#   both modified:      syssw/target/libs/makefile
#

注意,这是Unmerged paths部分。


你可以在命令行上点击git ls-files -u,它会列出有冲突的文件


这对我来说很管用:

<<<<<< HEAD'

or

git grep '<<<<<<< HEAD' | less -N


Git diff——检查

将显示包含冲突标记(包括行号)的文件列表。

例如:

> git diff --check
index-localhost.html:85: leftover conflict marker
index-localhost.html:87: leftover conflict marker
index-localhost.html:89: leftover conflict marker
index.html:85: leftover conflict marker
index.html:87: leftover conflict marker
index.html:89: leftover conflict marker

来源:https://ardalis.com/detect-git-conflict-markers


正如在其他答案中突出显示的那样,我们可以简单地使用命令git status,然后查找未合并路径下列出的文件:


假设你知道git根目录${GIT_ROOT}在哪里,你可以这样做,

 cat ${GIT_ROOT}/.git/MERGE_MSG | sed '1,/Conflicts/d'

我在这里的2美分(即使有很多很酷/有用的回应)

我在.gitconfig中创建了这个别名

[alias]
 ...
 conflicts = !git diff --name-only --diff-filter=U | grep -oE '[^/ ]+$'

它只会显示有冲突的文件的名称。不是他们的全部路线:)


下面是我用来列出适合bash命令行替换的修改文件

git diff --numstat -b -w | grep ^[1-9] | cut -f 3

要编辑列表,使用$(cmd)替换。

vi $(git diff --numstat -b -w | grep ^[1-9] | cut -f 3)

如果文件名中有空格,则无效。我尝试使用sed来转义或引用空格,输出列表看起来是正确的,但$()替换仍然没有达到预期的效果。


实用git向导https://github.com/makelinux/git-wizard分别计算未解决的冲突更改(冲突)和未合并的文件。冲突必须手动或使用mergetool解决。解决的未合并的更改可以添加和提交通常与git rebase -continue。


Jones Agyemang的回答对于大多数用例来说可能已经足够了,并且是我的解决方案的一个很好的起点。对于在Git Bent(我制作的Git包装器库)中编写脚本,我需要一些更健壮的东西。我正在发布我所编写的原型,它还不是完全脚本友好的

笔记

链接的答案检查<<<<<<< HEAD,它不工作的合并冲突使用git stash应用程序,有<<<<<<<更新的上游 我的解决方案确认了=======和>>>>>>>的存在 链接的答案肯定更有性能,因为它不需要做那么多 我的解决方案不提供行号

打印合并冲突的文件

您需要下面的str_split_line函数。

# Root git directory
dir="$(git rev-parse --show-toplevel)"
# Put the grep output into an array (see below)
str_split_line "$(grep -r "^<<<<<<< " "${dir})" files
bn="$(basename "${dir}")"
for i in "${files[@]}"; do 
    # Remove the matched string, so we're left with the file name  
    file="$(sed -e "s/:<<<<<<< .*//" <<< "${i}")"

    # Remove the path, keep the project dir's name  
    fileShort="${file#"${dir}"}"
    fileShort="${bn}${fileShort}"

    # Confirm merge divider & closer are present
    c1=$(grep -c "^=======" "${file}")
    c2=$(grep -c "^>>>>>>> " "${file}")
    if [[ c1 -gt 0 && c2 -gt 0 ]]; then
        echo "${fileShort} has a merge conflict"
    fi
done

输出

projectdir/file-name
projectdir/subdir/file-name

按行函数拆分字符串

如果你不想把它作为一个单独的函数,你可以复制这段代码

function str_split_line(){
# for IFS, see https://stackoverflow.com/questions/16831429/when-setting-ifs-to-split-on-newlines-why-is-it-necessary-to-include-a-backspac
IFS="
"
    declare -n lines=$2
    while read line; do
        lines+=("${line}")
    done <<< "${1}"
}

如果你在本地git存储库中工作,或者在patch -p1——merge <…是应用。

grep -rnw . -e '^<<<<<<<$'

对我来说,公认的答案并不管用。为了防止捕获

警告:[]中的LF将被CRLF取代。 该文件在您的工作目录中有其原始的行结束符

在Powershell中我使用了这种方法:

git ls-files -u| ForEach{($_.Split("`t"))|Select-Object -Last 1}| get-unique

只需阅读手册页的git状态,并过滤什么是需要的。

 git status --help

代码片段:

       For paths with merge conflicts, X and Y show the modification states of each side of the merge. For paths that do not have merge conflicts, X shows the status of the index, and Y shows the status of the work tree. For untracked
   paths, XY are ??. Other status codes can be interpreted as follows:

   •   ' ' = unmodified

   •   M = modified

   •   A = added

   •   D = deleted

   •   R = renamed

   •   C = copied

   •   U = updated but unmerged

   Ignored files are not listed, unless --ignored option is in effect, in which case XY are !!.

       X          Y     Meaning
       -------------------------------------------------
                [AMD]   not updated
       M        [ MD]   updated in index
       A        [ MD]   added to index
       D                deleted from index
       R        [ MD]   renamed in index
       C        [ MD]   copied in index
       [MARC]           index and work tree matches
       [ MARC]     M    work tree changed since index
       [ MARC]     D    deleted in work tree
       [ D]        R    renamed in work tree
       [ D]        C    copied in work tree
       -------------------------------------------------
       D           D    unmerged, both deleted
       A           U    unmerged, added by us
       U           D    unmerged, deleted by them
       U           A    unmerged, added by them
       D           U    unmerged, deleted by us
       A           A    unmerged, both added
       U           U    unmerged, both modified
       -------------------------------------------------
       ?           ?    untracked
       !           !    ignored
       -------------------------------------------------