Question

更新：示例存储库，https://github.com/so-gitdemo/so-gitdemorepo

在github repo的上下文中。如何轻松找到rev“b0430cee”？我知道我可以看一下，但这个存储库模仿的真实例子有十几个提交者和多个其他分支。不太容易使用检查。

如何在多次合并分支时找到分支创建修订版？

我知道这个问题：How to determine when a Git branch was created?

该解决方案似乎不适用于多次合并的分支。我们通常将错误修复从发布分支合并到主分支。也许我们甚至把这部分做错了......对git来说还是新手。

想象一下以下简单。真实的东西在多个人的主/分支上有更多的提交。还有几个发布分支（想想1.0,1.1,1.2,1.3）

        Future dev  ?
                    |
                    |
   Merge 1.0 back   *  ? Potential future fixes
                    |\ |
                    | \|  
                    |  \
           New work *  |
                    |  * Emergency bug fix
                    |  |
   Merge 1.0 back   *  |
                    |\ |
                    | \|
                    |  * Another bug fix
                    |  |
                    |  |
        New feature *  * First bugfix on branch 1.0
                    |  /
                    | /
                    |/
                    * Feature
                    |
                    |
                    |
                    * Some  feature
                    |
                    |
                    |
                    * The past (master)

我们仍然是git的新手并且正在制定管理版本和分支的最佳方法，我们已经决定我们需要追溯性地向repo添加一些标签。例如1.0分支用于1.0分支的开始，后来1.0.1标记用于修复版本。

后续红利问题：添加我想要的标签的最佳方法是什么？我应该在哪个版本上标记？首先提交新分支？或分支提交前的第一个常见提交？

Answer 1

在阅读这个问题时，我对你的要求有点反复。

如果你真的只想要一个分支的根，我想你想要像

这样的东西

git rev-list --merges --boundary branch1 branch2 | tail -1

如果您想验证分支实际上是相关的

git rev-list --left-right --merges --boundary branch1 branch2 | 
    grep '^-' | 
    tail -1 |
    cut -c2-

但是，你想要的漂亮很高

git merge-base branch1 branch2

此外，下次您需要漂亮的燕尾图时，以下内容将非常有用：

git show-branch # [--mergebase] branch1 branch2

使用git log可以获得更多控制权：

 git log --graph --left-right --merges --boundary HEAD MP26/MP26

>   commit 0118d9979d1d27f08fa14cddfffa3e9c2cd5fe9c
|\  Merge: 8958c53 e1cd319
| | Author: Seth Heeren <seth.heeren@xxxx>
| | Date:   Fri Feb 18 12:05:49 2011 +0100
| |
| |     Merge branch 'MP26' into tmp
| |
| o commit e1cd31926d01c08092a95226ac7b49bbea19ac92
|   Author: Seth Heeren <seth.heeren@xxxx>
|   Date:   Thu Feb 17 16:39:17 2011 +0100
|
|       xxxxx
|
o commit 8958c534b034cbb28bf1e853de0bfec0a9b0ddbb
  Author: Seth Heeren <seth.heeren@ocwduo.nl>
  Date:   Fri Feb 18 12:05:30 2011 +0100

      fixup

Git log还支持--decorate选项，以防您希望git show-branch显示分支名称

Answer 2

由于您添加了一个git repo ...我远程工作以测试内容。

如何轻松找到rev“b0430cee”？

在这种情况下，这个漂亮的oneliner为我做了这个工作：

git rev-list --reverse --topo-order --left-right --boundary 1.0...master | 
    grep "^>" -B1 |
    head -1 |
    cut -c2-

如果你想获得469c14a1fa8a40237700（New feature work），这对我有用：

git rev-list --reverse --topo-order --left-right --boundary 1.0...master | 
    grep "^>" |
    head -1 |
    cut -c2-

HTH

Answer 3

也许我误解了这个问题，但是分支是由提交定义的，并且该提交的每个祖先都包含在分支中。例如，假设emergency-bug-fix是一个分支，其图表中的提示位于Emergency bug fix - 该分支上最早的提交将是The past (master)。如果您只是查看提交图，那么“创建分支的修订版”不是一个明确定义的概念。

如果您只关心在特定存储库中创建分支的时间，您可以使用“reflog” - 例如，查看输出中的最后一行：

git reflog show emergency-bug-fix

但是，该命令的结果将不同于存储库到存储库，具体取决于在那里创建ref的时间，例如通过提取或推送。此外，默认情况下，reflog会在90天后过期，但可能不再拥有该信息。如果您有一个受祝福的中央存储库，您可以在那里进行相同的尝试，这可能会为您提供首次在集中式存储库中创建该ref的提交。但是，我不认为这是你想要的解决方案。

正如您已经正确制定的那样，最好只在您感兴趣的提交图中标记点。Magnus Skog's answer告诉您如何执行此操作。

Answer 4

在git中追溯添加标签非常容易。您需要做的就是将sha1哈希给git tag命令（感谢Sehe）：

git tag 1.0 abcd1232
git push origin 1.0

很难回答你的第二个问题，因为很难定义什么是“最好的”。在工作中，我们有一个开发分支，每个人都反对，当我们决定要发布时，我们创建一个发布分支，例如rel-1.0和那个分支一直存在，直到我们决定完成它。然后我们将它合并到master，标记为1.0并删除发布分支。因此，我们的标签应该始终被视为神圣和稳定。所以在我们的例子中，它总是在我们将发布分支合并到master中时创建的合并提交。

在git中，如何找到创建分支的修订版？

4 个答案: