Git：签出到标签后2次提交

Question

Knowing the following scheme :

Yellow line is Master branch. Red line is Develop branch.

I am on Master on tag 6.2.1. My need would be to get automatically the sha1 of the commit circled in blue, checking out to this sha1 and create my branch from this sha1. This commit is not the last commit of develop.

The thing to do could consists in :

• getting the sha1 of tag 6.2.1 : git log --oneline | head -1 | cut -d ' ' -f1 git log --oneline | head -1 | cut -d ' ' -f1
• getting the parent of tag 6.2.1 : called commit 'P'
• getting the following commit of 'P' called commit 'C1' which should be on develop
• getting the following commit of 'C1' called 'C2' also on develop.

Currently I have to manually go on Gitlab, get the related sha1 before checking out and then create my branch.

Answer 1

There is a way, but there is a potential problem.

A tag name identifies a commit.

More specifically and precisely, a tag name like v2.1 is the short version of the fully-qualified reference name refs/tags/v2.1 , and any Git reference identifies some Git object. All branch names, such as master which is short for refs/heads/master , are constrained to identify only a commit object. Tag names usually identify either a commit object—Git call this a lightweight tag —or an annotated tag object, which then goes on to identify the commit. In either case, the special gitrevisions syntax name ^{commit} refers to the specific commit, if you need that (usually you don't—Git figures out that, eg, git checkout needs a commit and adds the ^{commit} automatically).

The problem is, you don't want the commit the tag identifies. You want a nearby commit. You said "two commits after " and this is a problem: there's no such thing as a commit after another commit. There are only commits before another commit.

Objection, your honor!

How can there not be a commit after a commit if there is a commit before a commit? For instance, let's write down four commits in a row:

A <- B <- C <- D

In Git, commit D stores the ID of its parent commit, which is commit C . So given D it's very easy to step back to C . Likewise, C store's B 's ID, and B stores A 's. (If A is the very first commit ever, there is no parent: you cannot step back, and A is a root commit . A root commit is one that has no parent.)

The problem here is that there can be more than one commit before a commit, or after a commit, for that matter. Instead of just the above, consider this graph fragment:

A--B--C--D---H   <-- master
    \       /
     E--F--G     <-- feature

Commit H , which is the tip of branch master , is a merge commit. It has two parents: D and G . When we examine commit H we see something like this (with different numbers):

$ git show master
commit 3e5c63943d35be1804d302c0393affc4916c3dc3
Merge: c13c783 20690b2

This means it has two parents, c13c783... and 20690b2... . Which one is the commit before commit H ?

So the answer to the objection is that there isn't a commit before a commit, there are possibly- many (often 1, sometimes 2, rarer but occasionally zero, or three-or-more) commits before another commit. Likewise, there may be none, or two or more, commits after another commit.

To find the commit(s) you want , you need more information.

More information

In general, moving backwards is easy. The first (and often the only ) parent of a commit is usually the interesting one, as it's the commit that was on the branch before that commit got added to that branch. That is, while commit H has both D and G as parents, if master used to point to D and now points to H , it's H 's first parent we want.

Gitrevisions has a quick and easy syntax for following first-parents: you simply add a tilde ~ character and a count of how many first-parents to step back. So to go two steps back from v2.1 , following only first-parents, just write v2.1~2 :

git checkout -b newbranch v2.1~2

and you're done.

Going forward is harder. Git only stores backwards links, so what you need to do is provide a name-or-identity of a later commit, from which Git can work backwards to reach your known (tagged) commit. For instance, if we have a tag pointing to commit C and we want to move forward two steps (to D and then to H ), we would give Git two bits of information:

1. please end at v2.1
2. and start from master

and have it enumerate all the commits between those two points, and then pick the one two steps "closer to master " than the final one at v2.1 . Let's say at this point that there are even more commits on master now, so the drawing looks like this:

   tag:v2.1
      |
      v
A--B--C--D---H--I   <-- master
    \       /
     E--F--G     <-- feature

To find H this way, we use git rev-list and yet more gitrevisions syntax . (By now it should be obvious that learning gitrevisions syntax is critical to using Git .)

git rev-list v2.1..master

The two-dot syntax here means " don't include v2.1 itself", so this will list commits starting from master and working back to the commit after v2.1 :

0fbc341...   # id of I
a9315c3...   # id of H
9911231...   # id of D

We take the last two of these IDs, throw away the last one of these IDs, and get a9315c3 , which is the ID of H .

But there's still a potential problem

What if the graph looks more like this?

   tag:v2.1
      |
      v
A--B--C--D---------H--I   <-- master
          \       /
           E--F--G     <-- feature

We noted earlier that using the ~ notation uses the first parent. We can do that here, using git rev-list --first-parent v2.1..master . That will keep Git from listing GFE , which will make sure we find H instead of E .

It's a good idea to add --topo-order to the rev-list command as well, because otherwise these commits are listed in commit-date order, and if the date/times were ever screwed up on one of the computers involved in making the repository, the commits may be listed in the wrong order.

There is also the --ancestry-path option, which is useful in some cases (maybe not applicable to your own case): it makes sure that git rev-list lists only commits that are descendants of the left side of the .. operation. You would use this where the --first-parent is not wanted, eg:

...--o--*--A--B--C
      \        \  \
       D--E--F--G--H   <-- branch

If we want the commit "three steps" after tagged commit * , that could be C or G . Using git rev-list tag..branch will print all of A through H (in some order). Adding --first-parent will cut off either G or C —only one of those two can be the first parent of H —and if you want to look at both you cannot use --first-parent . Adding --ancestry-path will make git rev-list omit DEF ; the rest will still come out, in some order. Adding --topo-order will guarantee that B comes out second-to-last and A comes out last (remember, Git is working backwards), with C and G in any order before them, and H first.

That's not a complete solution, but there is no complete solution, if you have a branch-and-merge-y graph like this.

Anyway, pick some subset of these options. If you know your graphs are first-parent-able, then, eg:

git rev-list --topo-order --first-parent tag .. branchname | tail -2 | head -1

will get you the hash you want.

(For another slightly subtle trick, add --reverse to reverse the printout order from git rev-list and then use sed -n -e 2p to print the second line. Note, however, that you cannot use git rev-list 's -n flag here, as it counts and stops from the unreversed list, and we don't know how many commits there will be, we want the second-from-bottom, however many that is.)

Answer 2

Open git bash, go to selected directory then run the following commands. To get SHA1 run command

git log branchname --oneline

It will have the sha1 next to the commit message

git branch branchname <sha1-of-commit>