奇怪的 git 合并问题

Question

这是 gitk 目前在我们的一个项目中的样子：

https://dl.dropbox。 com/u/2582508/gitk.png

据我们所知，这显然是在远程分支完成一次“git merge”之后发生的 - 我们不确定为什么或发生了什么。知道这里发生了什么吗？

更重要的是，修复它的最佳方法是什么？这些合并提交是空的，但是当执行“git rebase -i”时，合并提交通常似乎不会出现。

最重要的是，我不想让历史与其他克隆不兼容，即它们仍然应该能够与其拉/推/合并。这可能吗？

Answer 1

这是某人使用 git pull（或者等效地，git fetch 和 git merge）更新其项目的结果。想象一下，您的存储库看起来像这样：

o---o---o [origin/master]
         \
          A---B---C [master]

也就是说，您已经在原始仓库。

与此同时，其他人进行更改并将其推送到共享存储库。如果你然后运行 ​​git fetch ，你的存储库看起来像这样：

o---o---o---D---E---F [origin/master]
         \
          A---B---C [master]

现在，如果你运行 git merge （记住：git pull 只是 git fetch 后跟 git merge）。你会得到这样的结果：

o---o---o---D---E---F [origin/master]
         \           \
          A---B---C---G [master]

假设一切顺利，G可能只是一个“愚蠢的”合并提交；从技术上讲，G 的状态与 F 和 C 不同，因此必须以不同方式考虑。

现在，如果你推动这个改变，你会得到这个：

o---o---o---D---E---F 
         \           \
          A---B---C---G [origin/master]

如果你继续开发，你会得到这个：

o---o---o---D---E---F 
         \           \
          A---B---C---G [origin/master]
                       \
                        H---I---J [master]

现在，如果你继续这样做（并且如果很多人继续这样做），你最终会得到一棵像这样的树你照片中的那个。这并不是“错误”，但很多人不喜欢它，因为它使得发展历史很难遵循。

这个问题的解决办法就是教人们rebase。变基将（正如您所指出的）远程无用的合并提交，并为您提供更清晰的历史记录。在上面的例子中，你最终会得到一个线性的开发历史。这更容易遵循。但是，您需要知道，在变基之后，您需要重建并重新测试您的代码……仅仅因为代码很容易合并并不意味着结果是正确的。

如果您使用中央存储库来共享官方开发线，您可以实现一个预接收钩子来检测这些自动（“愚蠢”/“无用”）合并提交并拒绝推送 - 强制用户重新设置基准。实际上，您希望挂钩查找默认的合并提交消息...因此，如果您确实想保留合并提交（有时这是有意义的），您至少必须编写一条智能提交消息。

这是一个钩子示例。我去掉了一些额外的东西，所以我没有测试它。

#!/bin/bash

# This script is based on Gnome's pre-receive-check-policy hook.
# This script *only* checks for extraneous merge commits.

# Used in some of the messages
server=git.wherever.com

GIT_DIR=$(git rev-parse --git-dir 2>/dev/null)

in_import() {
    test -e "$GIT_DIR/pending"
}

forced() {
    test -n "$GNOME_GIT_FORCE"
}

check_commit() {
    commit=$1

    subject="$(git log $commit -1 --pretty=format:%s)"
    if expr "$subject" : ".*Merge branch.*of.*\(git\|ssh\):" > /dev/null 2>&1; then
          if ! in_import && ! forced ; then
                cat &2
---
The commit:

EOF
        git log $commit -1 >&2
        cat &2

Looks like it was produced by typing 'git pull' without the --rebase
option when you had local changes. Running 'git  pull --rebase' now
will fix the problem. Then please try, 'git push' again. Please see:

  http://live.gnome.org/Git/Help/ExtraMergeCommits
---
EOF
        exit 1
          fi
    fi
}

check_ref_update() {
    oldrev=$1
    newrev=$2
    refname=$3

    change_type=update
    if expr $oldrev : "^0\+$" > /dev/null 2>&1; then
    change_type=create
    fi

    if expr $newrev : "^0\+$" > /dev/null 2>&1; then
          if [ x$change_type = xcreate ] ; then
             # Deleting an invalid ref, allow
                return 0
          fi
          change_type=delete
    fi

    case $refname in
     refs/heads/*)
        # Branch update
        branchname=${refname#refs/heads/}

        range=
        # For new commits introduced with this branch update, we want to
        # run some checks to catch common mistakes.
        #
        # Expression here is same as in post-receive-notify-cia; we take 
        # all the branches in the repo, as "^/ref/heads/branchname", other
       # than the branch we are actualy committing to, and exclude commits
       # already on those branches from the list of commits between
       # $oldrev and $newrev.

        if [ -n "$range" ] ; then
        for merged in $(git rev-parse --symbolic-full-name --not --branches | \
                    egrep -v "^\^$refname$" | \
            git rev-list --reverse --stdin "$range"); do
            check_commit $merged
        done
        fi
        ;;
    esac

    return 0
}

if [ $# = 3 ] ; then
    check_ref_update $@
else
    while read oldrev newrev refname; do
    check_ref_update $oldrev $newrev $refname
    done
fi

exit 0