Git 分支从哪里开始以及它的长度是多少？

我时不时地被问到，git 上的某个分支在什么提交上启动，或者是否在特定分支上创建了某个提交。分支的终点非常清楚：那就是分支标签所在的位置。但是——从哪里开始呢？简单的答案是：在我们的提交中created那个分支。但据我现在所知，这些信息在第一次提交后就丢失了，这就是我问这个问题的原因。

只要我们知道我们分支的提交，我们就可以画图来明确：

A - B - C - - - - J     [master]
     \
      D - E - F - G     [branch-A]
           \
            H - - I     [branch-B]

我在提交时创建了分支 BE这就是“开始”。我知道这一点，因为我做到了。但其他人能以同样的方式认识它吗？我们可以像这样绘制相同的图表：

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

所以，现在看一下图表，哪个分支开始于E，哪一个在B？是否提交D是两个分支的成员还是我们可以清楚地确定它属于 A 分支还是 B 分支？

这听起来有点哲学，但事实并非如此。主管有时想知道，一个分支何时启动（它通常标志着任务的开始）以及某些更改属于哪个分支（以了解某些更改的目的 - 工作是否需要），我会想知道 git 是否提供信息（工具、命令）或定义来正确回答这些问题。

在 Git 中，您可以说每个分支都从根提交开始，这确实是事实。但我想这对你来说没有多大帮助。您可以做的是定义与其他分支相关的“分支的开始”。执行此操作的一种方法是使用

git show-branch branch1 branch2 ... branchN

这将在输出底部显示所有指定分支之间的公共提交（如果实际上存在公共提交）。

这是一个例子Linux 内核 Git 文档show-branch https://www.kernel.org/pub/software/scm/git/docs/git-show-branch.html

$ git show-branch master fixes mhf
* [master] Add 'git show-branch'.
 ! [fixes] Introduce "reset type" flag to "git reset"
  ! [mhf] Allow "+remote:local" refspec to cause --force when fetching.
---
  + [mhf] Allow "+remote:local" refspec to cause --force when fetching.
  + [mhf~1] Use git-octopus when pulling more than one heads.
 +  [fixes] Introduce "reset type" flag to "git reset"
  + [mhf~2] "git fetch --force".
  + [mhf~3] Use .git/remote/origin, not .git/branches/origin.
  + [mhf~4] Make "git pull" and "git fetch" default to origin
  + [mhf~5] Infamous 'octopus merge'
  + [mhf~6] Retire git-parse-remote.
  + [mhf~7] Multi-head fetch.
  + [mhf~8] Start adding the $GIT_DIR/remotes/ support.
*++ [master] Add 'git show-branch'.

在那个例子中，master正在与fixes and mhf分支机构。将此输出视为一个表，每个分支由其自己的列表示，每个提交都有自己的行。包含提交的分支将有一个+ or -显示在该提交所在行的列中。

在输出的最底部，您将看到所有 3 个分支共享一个共同的祖先提交，并且它实际上是head提交master:

*++ [master] Add 'git show-branch'.

这意味着两者fixes and mhf从该提交中分支出来master.

替代解决方案

当然，这只是确定 Git 中公共基础提交的一种可能方法。其他方式包括git merge-base寻找共同的祖先，以及git log --all --decorate --graph --oneline or gitk --all可视化分支并查看它们分歧的地方（尽管如果有大量提交，很快就会变得困难）。

原贴者的其他问题

对于这些问题，你有：

是否提交D是两个分支的成员还是我们可以明确决定它是否属于branch-A or branch-B?

D是两个分支的成员，它是两个分支的祖先提交。

主管有时想知道，当分支启动时（通常标志着任务的开始）...

在 Git 中，您可以重写整个提交树及其分支的历史记录，因此when分支“开始”并不像 TFS 或 SVN 那样一成不变。你可以rebase分支到 Git 树中的任何时间点，甚至将其放在根提交之前！因此，您可以使用它在树中您想要的任何时间点“启动”任务。

这是一个常见的用例git rebase，将分支与上游分支的最新更改同步，将它们沿着提交图及时“向前”推送，就好像您“刚刚开始”在该分支上工作一样，即使您实际上一直在处理它一阵子。如果您愿意，您甚至可以沿着提交图及时推回分支（尽管您可能必须解决很多冲突，具体取决于分支内容......或者也许您不会）。您甚至可以在开发历史记录的中间插入或删除分支（尽管这样做可能会更改许多提交的提交shas）。重写历史记录是 Git 的主要功能之一，这使得它如此强大和灵活。

这就是为什么提交同时带有创作日期（最初创作提交的时间）和提交日期（最后一次提交到提交树的时间）的原因。您可以将它们视为类似于创建时间日期和上次修改时间日期。

主管有时想知道...某些更改属于哪个分支（为了达到某些改变的目的——工作是否需要）。

同样，由于 Git 允许您重写历史记录，因此您可以（重新）将一组更改基于您想要的提交图中的几乎任何分支/提交。git rebase从字面上看，您可以自由地移动整个分支（尽管您可能需要在移动时解决冲突，具体取决于您将分支移动到的位置及其包含的内容）。

话虽如此，您可以在 Git 中用来确定哪些分支或标签包含一组更改的工具是--contains:

# Which branches contains commit X?
git branch --all --contains X

# Which tags contains commit X?
git tag --contains X