目录 搜索
Guides gitattributes giteveryday gitglossary gitignore gitmodules gitrevisions gittutorial gitworkflows Administration git archive git bundle git clean git filter-branch git fsck git gc git instaweb git reflog Basic Snapshotting git add git commit git diff git mv git reset git rm git status Branching and Merging git branch git checkout git log git merge git mergetool git stash git tag Debugging git bisect git blame git grep Email git am git format-patch git request-pull git send-email External Systems git fast-import git svn Getting and Creating Projects git clone git init Git git annotate git archimport git bisect-lk2009 git check-attr git check-mailmap git check-ref-format git checkout-index git cherry git citool git column git credential git credential-cache git credential-store git cvsexportcommit git cvsimport git cvsserver git diff-files git diff-tree git difftool git fast-export git fetch-pack git fmt-merge-msg git get-tar-commit-id git gui git http-backend git http-fetch git http-push git imap-send git index-pack git interpret-trailers git ls-remote git ls-tree git mailinfo git mailsplit git merge-file git merge-index git merge-one-file git merge-tree git mktag git mktree git name-rev git notes git p4 git pack-objects git pack-redundant git pack-refs git parse-remote git patch-id git prune git prune-packed git quiltimport git receive-pack git remote-ext git remote-fd git remote-testgit git repack git replace git rerere git send-pack git sh-i18n git sh-setup git shell git show-branch git show-index git stripspace git unpack-file git unpack-objects git upload-archive git upload-pack git var git verify-commit git verify-tag git whatchanged git worktree Inspection and Comparison git describe git shortlog git show Miscellaneous api credentials api index gitcli gitcore tutorial gitcredentials gitcvs migration gitdiffcore githooks gitk gitnamespaces gitremote helpers gitrepository layout gitsubmodules gittutorial 2 gitweb gitweb.conf pack format User Manual Patching git apply git cherry-pick git rebase git revert Plumbing Commands git cat-file git check-ignore git commit-tree git count-objects git diff-index git for-each-ref git hash-object git ls-files git merge-base git read-tree git rev-list git rev-parse git show-ref git symbolic-ref git update-index git update-ref git verify-pack git write-tree Server Admin git daemon git update-server-info Setup and Config git git config git help Sharing and Updating Projects git fetch git pull git push git remote git submodule
文字

命名

git-merge-base  - 为合并找到尽可能好的共同祖先

概要

git merge-base [-a|--all] <commit> <commit>…
git merge-base [-a|--all] --octopus <commit>…
git merge-base --is-ancestor <commit> <commit>git merge-base --independent <commit>…
git merge-base --fork-point <ref> [<commit>]

描述

git merge-base在两次提交之间找到最佳共同祖先以用于三向合并。better如果后者是前者的祖先,一个共同的祖先是另一个共同的祖先。一个没有任何更好的共同祖先的共同祖先是a best common ancestor,即a merge base。请注意,一对提交可能有多个合并基础。

操作模式

作为最常见的特例,在命令行中只指定两个提交意味着计算给定两个提交之间的合并基础。

更一般地说,在计算合并基数的两个提交中,有一个由命令行上的第一个提交参数指定; 另一个提交是一个(可能是假设的)提交,它是命令行上所有其余提交的合并。

因此,merge base如果指定了两个以上的提交,则不一定包含在每个提交参数中。这与使用该--merge-base选项时不同于git-show-branch [1] 。

--octopus

计算所有提交的提交的最佳共同祖先,准备进行n路合并。这模仿的行为git show-branch --merge-base

--independent

不是打印合并基础,而是使用相同的祖先打印提供的提交的最小子集。换句话说,在提交的提交中,列出那些无法从其他提供的提交。这模仿的行为git show-branch --independent

--is-ancestor

检查第一个<commit>是否是第二个<commit>的祖先,如果为true,则退出状态0,否则退出状态1。错误通过不为1的非零状态发出信号。

--fork-point

查找分支(或任何导致<commit>的历史记录)从另一个分支(或任何引用)<ref>分支的点。这不仅仅是寻找两个提交的共同祖先,而且还考虑了<ref>的引用日志,以查看引用<commit>的历史是否来自分支的早期化身<ref>(参见下面的这个模式)。

选项

-a   --all

输出提交的所有合并基础,而不仅仅是一个。

讨论

给定两个提交ABgit merge-base A B将输出一个提交这从到达AB通过父关系。

例如,对于这种拓扑结构:

         o---o---o---B        /---o---1---o---o---o---A

AB之间的合并基础是1

鉴于三个提交AB并且Cgit merge-base A B C将计算之间的合并基础A和假设的承诺M,这是之间的合并BC。例如,对于这种拓扑结构:

       o---o---o---o---C      /     /   o---o---o---B    /   /---2---1---o---o---o---A

结果git merge-base A B C1。这是因为合并相当于拓扑承诺M之间BC为:

       o---o---o---o---o      /                 \     /   o---o---o---o---M    /   /---2---1---o---o---o---A

结果git merge-base A M1。提交2也是之间一个共同的祖先AM,不过1是一个更好的共同的祖先,因为2是的祖先1。因此,2不是合并基础。

结果git merge-base --octopus A B C2,因为2是所有提交的最佳共同祖先。

当历史涉及纵横交错时best,两个提交可以有多个共同的祖先。例如,对于这种拓扑结构:

---1---o---A
    \ /
     X    / \---2---o---o---B

两个12是A的合并底座和B.既不一个比另一个(均为更好best合并碱基)。如果--all没有给出选项,则没有指定哪一个输出最好。

检查两个提交A和B之间的“快速前进”的常见方法是(或者至少用于)计算A和B之间的合并基础,并检查它是否与A相同,在这种情况下,A是B的祖先。你会在老的脚本中看到这种习惯用法。

A=$(git rev-parse --verify A)if test "$A" = "$(git merge-base A B)"then        ... A is an ancestor of B ...fi

在现代的git中,你可以用更直接的方式来说明这一点:

if git merge-base --is-ancestor A B
then        ... A is an ancestor of B ...fi

代替。

讨论叉点模式

topic创建分支之后git checkout -b topic origin/master,远程跟踪分支的历史origin/master可能已经被重新卷绕和重建,导致这种形状的历史记录:

                 o---B1                /---o---o---B2--o---o---o---B (origin/master)
        \
         B3
          \           Derived (topic)

在那里origin/master用于指向提交B3,B2,B1,现在它指向B,并且当你在B3 topic时,你的分支在它的顶部被启动origin/master。此模式使用reflog origin/master来查找B3作为分叉点,以便topic可以在更新origin/master的基础上重新绑定:

$ fork_point=$(git merge-base --fork-point origin/master topic)$ git rebase --onto origin/master $fork_point topic
上一篇: 下一篇: