当前位置：文江博客话题详情

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

发布于 2024-11-07 22:25:16 字数 1520 浏览 6 评论 0原文

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

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

当分支被多次合并后，如何找到分支创建修订版本？

我知道这个问题：如何确定 Git 分支何时创建？

该解决方案似乎不适用于以下分支：已被合并多次。我们通常会将错误修复从发布分支合并回主分支。也许我们甚至在这部分做错了......对 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 还很陌生，正在研究管理发布和分支的最佳方法，并且我们决定需要向存储库追溯添加一些标签。例如，1.0 分支的开头使用 1.0 标签，之后的 bug 修复版本使用 1.0.1 标签。

后续奖金问题：添加我想要的标签的最佳方式是什么？我应该标记哪个版本？首先提交新分支？或者分支提交之前的第一次公共提交？

原文

UPDATE: example repository, https://github.com/so-gitdemo/so-gitdemorepo

In the context of the github repo. How can I easily locate rev "b0430cee"? I know I can just look, but the real example that this repository mimics has a dozen committers and multiple other branches. Not quite as easy to use inspection.

How can I find the branch creation revision when the branch has been merged multiple times?

I am aware of this question: How to determine when a Git branch was created?

The solution does not appear to work for a branch that has been merged multiple times. We typically merge bug fixes back from the release branch to the main branch. Maybe we're even doing this part wrong ... still new to git.

Imagine the following simple. The real thing has MANY more commits on master/branch from multiple people. There are also several release branches (think 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)

We're still new to git and working out the best way to manage releases and branches and we've decided that we need to retroactively add some tags to the repo. Such as a 1.0 tag for the beginnning of the 1.0 branch and later 1.0.1 tags to bugfix releases.

Follow-up bonus question: What is the best way to add the tags that I want? and at which revision should I tag? first commit on new branch? or first common commit before branch commit?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

離人涙 2024-11-14 22:25:16

由于您添加了 git 存储库...我远程工作以进行测试。

如何轻松找到版本“b0430cee”？

在这种情况下，这个漂亮的单行代码为我完成了这项工作：

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

如果你想获得 469c14a1fa8a40237700 （新功能工作），这对我有用：

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

HTH

Since you added a git repo... I worked remotely to get things tested.

How can I easily locate rev "b0430cee"?

In that case, this pretty oneliner did the job for me:

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

If you wanted to get 469c14a1fa8a40237700 (New feature work) instead, this works for me:

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

HTH

回复收藏 0 原文

滥情稳全场 2024-11-14 22:25:16

在阅读问题时，我对你所问的问题有些犹豫。

如果你真的只想要一个分支的根，我想你想要类似的东西

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 <[email protected]>
  Date:   Fri Feb 18 12:05:30 2011 +0100

      fixup

Git log 还支持 --decorate 选项，以防你喜欢 git show 中显示的分支名称-分支

I'm thrown a bit back and forth on what you are asking while reading the question.

If you really wanted just the root of a branch, I think you wanted something like

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

If you wanted to verify that the branches were in fact related

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

However, chances are pretty high that you want

git merge-base branch1 branch2

Also, the following will prove helpful next time you want pretty dovetail diagrams:

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

You can get slightly more control using 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 <[email protected]>
  Date:   Fri Feb 18 12:05:30 2011 +0100

      fixup

Git log also supports the --decorate option in case you like the branch name display from git show-branch

回复收藏 0 原文

淡淡绿茶香 2024-11-14 22:25:16

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

如果您只关心何时在特定存储库中创建分支，您可以使用“reflog” - 例如，查看

git reflog show emergency-bug-fix

以下输出中的最后一行：该命令将因存储库而异，具体取决于在那里创建引用的时间，例如通过获取或推送。此外，默认情况下，reflog 条目会在 90 天后过期，它可能不再包含该信息。如果您有一个受祝福的中央存储库，您可以在那里进行相同的尝试，这可能会为您提供在中央存储库中首次创建该引用的提交。但是，我认为这不是您想要的解决方案。

正如您已经正确计算出的那样，最好只在提交图中标记您感兴趣的点。 Magnus Skog 的回答告诉您该怎么做那。

Perhaps I misunderstand the question, but branches are defined by the commit at their tip, and every ancestor of that commit is contained in the branch. For example, suppose emergency-bug-fix is a branch whose tip is at Emergency bug fix in your diagram - the oldest commit on that branch will be The past (master). The "revision at which a branch was created" isn't a well-defined concept if you just look at the commit graph.

If you're just concerned about when a branch was created in a particular repository, you could use the "reflog" - for example, look at the last line in the output of:

git reflog show emergency-bug-fix

However, the results from that command will be different from repository to repository, depending on when the ref was created there, for example by fetching or pushing. Also, by default the reflog expires entries after 90 days, it may not have that information any more. If you have a blessed central repository, you could do the try the same there, and that might give you the commit where that ref was first created in the centralized repository. I don't think that's the solution you want, however.

As you've correctly worked out, it's a better idea to just tag points in the commit graph that you're interested in. Magnus Skog's answer tells you how to do that.

回复收藏 0 原文

你在我安 2024-11-14 22:25:16

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

git tag 1.0 abcd1232
git push origin 1.0

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

It's very easy to add tags retroactively in git. All you need to do is to give the sha1 hash to git tag command (thanks Sehe):

git tag 1.0 abcd1232
git push origin 1.0

Hard to answer your second question since it's hard to define what is "best". At work we have a develop branch that everyone work against and when we decide that we want to release, we create a release branch, e.g. rel-1.0 and that branch lives until we decide that we are done with it. Then we merge it into master, tag with 1.0 and delete the release branch. So a tag for us should always be regarded as holy and as stabile as it can get. So in our case it's always the merge commit that is created when we merge the release branch into master.

回复收藏 0 原文

~没有更多了~