In git, how can I find the revision at which a branch was created?
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?
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
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 <seth.heeren@ocwduo.nl>
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
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.
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.
精彩评论