735

Is there a way to find out what branch a commit comes from given its SHA-1 hash value?

Bonus points if you can tell me how to accomplish this using Ruby Grit.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Ethan Gunderson
  • 9,589
  • 8
  • 27
  • 29
  • 10
    The different methods below are pragmatic, useful, working ways to *infer* a *probable* answer, but let's note that in git the question itself is a misunderstanding, commits don't come from branches. Branches come and go, they move, only commits represent the real repo history. Then again, this is not a way to say below solutions are bad. Just know **none** of them gives a fully trustable answer, which is unobtainable by design in git. (A simple case is deleted branches : I branch, I commit twice, I merge into another branch, I delete the first branch. Where does the commit "come" from? – RomainValeri Sep 03 '19 at 16:02
  • 1
    I have a case where I explicitly pull a depth 1 shallow clone from a tag. It's cheap and easy and efficient... and until now did everything I wanted beautifully. Now that I'd like to know which branch the tag was on, I'm hosed, at least for that detail. You can't always go home, lol – Paul Hodges Dec 12 '19 at 21:12

15 Answers15

970

While Dav is correct that the information isn't directly stored, that doesn't mean you can't ever find out. Here are a few things you can do.

Find branches the commit is on

git branch -a --contains <commit>

This will tell you all branches which have the given commit in their history. Obviously this is less useful if the commit's already been merged.

Search the reflogs

If you are working in the repository in which the commit was made, you can search the reflogs for the line for that commit. Reflogs older than 90 days are pruned by git-gc, so if the commit's too old, you won't find it. That said, you can do this:

git reflog show --all | grep a871742

to find commit a871742. Note that you MUST use the abbreviatd 7 first digits of the commit. The output should be something like this:

a871742 refs/heads/completion@{0}: commit (amend): mpc-completion: total rewrite

indicating that the commit was made on the branch "completion". The default output shows abbreviated commit hashes, so be sure not to search for the full hash or you won't find anything.

git reflog show is actually just an alias for git log -g --abbrev-commit --pretty=oneline, so if you want to fiddle with the output format to make different things available to grep for, that's your starting point!

If you're not working in the repository where the commit was made, the best you can do in this case is examine the reflogs and find when the commit was first introduced to your repository; with any luck, you fetched the branch it was committed to. This is a bit more complex, because you can't walk both the commit tree and reflogs simultaneously. You'd want to parse the reflog output, examining each hash to see if it contains the desired commit or not.

Find a subsequent merge commit

This is workflow-dependent, but with good workflows, commits are made on development branches which are then merged in. You could do this:

git log --merges <commit>..

to see merge commits that have the given commit as an ancestor. (If the commit was only merged once, the first one should be the merge you're after; otherwise you'll have to examine a few, I suppose.) The merge commit message should contain the branch name that was merged.

If you want to be able to count on doing this, you may want to use the --no-ff option to git merge to force merge commit creation even in the fast-forward case. (Don't get too eager, though. That could become obfuscating if overused.) VonC's answer to a related question helpfully elaborates on this topic.

rogerdpack
  • 50,731
  • 31
  • 212
  • 332
Cascabel
  • 422,485
  • 65
  • 357
  • 307
  • 5
    +1. The sheer absence of information for that particular issue makes you wonder if it is actually a problem? Branches can change, be renamed or be deleted at any time. May be `git describe` is enough, for (annotated) tags can be viewed as more significant than branches. – VonC Apr 25 '10 at 09:48
  • 9
    I definitely agree - branches are meant to be lightweight and flexible. If you do adopt a workflow in which that information becomes important, you can use the `--no-ff` option to make sure there's always a merge commit, so you can always trace the path of a given commit as it's merged toward master. – Cascabel May 17 '10 at 17:35
  • see [my answer](http://stackoverflow.com/questions/2706797/git-finding-what-branch-a-commit-came-from/3772472#3772472) referencing Seth's Perl script, for an interesting implementation of that search algorithm. – VonC Sep 22 '10 at 18:33
  • 34
    FYI, if you want to find commits that only exist on the remote, add the `-a` flag to the first command e.g. `git branch -a --contains ` – Jonathan Day Oct 26 '11 at 03:48
  • 8
    @JonathanDay: No, that will find commits on any branch. If you want *only* ones on the remote, use `-r`. – Cascabel Oct 26 '11 at 05:34
  • Thanks @Jefromi - I worded my comment poorly, that was what I meant! – Jonathan Day Oct 26 '11 at 22:56
  • 4
    @VonC and Jefromi: I think the obvious use-case for knowing what branch a commit was created on is to determine which feature the change is part of. We use a different branch for each feature then merge it back into a release branch. It can be really difficult to tell at a glance which feature a commit was originally part of with git, since we can't tell one branch from another. Comments and tags help but it shouldn't be so hard. – Simon Tewsi May 13 '13 at 03:20
  • 7
    @SimonTewsi Like I said, if it's really an issue, use `merge --no-ff` to reliably record the branch name when you merge. But otherwise, think of branch names as temporary short labels, and commit descriptions as permanent ones. "What short name did we refer to this by during development?" should really not be as important a question as "what does this commit do?" – Cascabel May 15 '13 at 14:29
  • @Jefromi: I like your idea of branch names as temporary short labels, it's a useful concept. – Simon Tewsi May 16 '13 at 12:43
  • @Jefromi: Many organisations put a ticket tracking ID in the branch name which helps answer the question "Why was this change made?" – Will Sheppard May 06 '16 at 15:19
  • @WillSheppard That just brings things back to writing good commit messages, though. If that tracking is important for the commits made on that branch, that ID should be going in the commit message. You can still put it in the branch if you want, but it's not a replacement for good commit messages. – Cascabel May 06 '16 at 15:25
  • 3
    @Jefromi The ticket ID is metadata. Why should people write it a hundred times and have it take up space in the commit message if it can be done in one central place instead? The commit message only describes why this specific commit was made, while the tracking ticket describes the thinking and background behind a coherent set of changes. – Will Sheppard May 06 '16 at 15:32
  • @WillSheppard: Totally agree with your comment about ticket IDs. We name the feature branch for the ticket ID. – Simon Tewsi Nov 28 '16 at 21:19
  • 1
    `git branch --contains ` This just outputs the current branch... – Cerin Jan 05 '18 at 00:25
  • **Scripting**: To get output without `* master` see [this answer](https://stackoverflow.com/a/52906108/5353461) – Tom Hale Oct 20 '18 at 13:29
  • Any idea why this returns `* (no branch)` for me on some machines? – Alejandro Cotilla Nov 05 '18 at 18:04
  • correction for the `git branch -a --contains ` it is not only for showing only remote branches as was said before, but for showing all the branches locals and remotes; – Nikita Nov 21 '18 at 12:20
201

This simple command works like a charm:

git name-rev <SHA>

For example (where test-branch is the branch name):

git name-rev 651ad3a
251ad3a remotes/origin/test-branch

Even this is working for complex scenarios, like:

origin/branchA/
              /branchB
                      /commit<SHA1>
                                   /commit<SHA2>

Here git name-rev commit<SHA2> returns branchB.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
khichar.anil
  • 3,871
  • 1
  • 21
  • 20
  • 3
    You saved my day. This is the perfect solution. – Taco Mar 08 '18 at 19:56
  • 12
    And it took only 8 years for this perfect solution. Thanks! – S1J0 Mar 08 '18 at 23:29
  • 9
    I found `git name-rev --name-only ` to be more useful for getting only the branch name. My question... Can it return more than one branch in any circumstance? – Dean Kayton Jul 31 '19 at 07:59
  • 2
    This should be the best answer. – JCollier Jan 27 '20 at 21:52
  • 1
    Thank you @JCollier for your kind words. – khichar.anil Feb 11 '20 at 22:39
  • 2
    If you want to find only branch name and except tags following command can be used: `git name-rev --refs="refs/heads/*" --name-only ` – Andrey Semakin Feb 17 '20 at 05:51
  • 1
    Unfortunately, this only works for a short time after the merge, before the ref gets garbage collected. It is the same limitation as for the method "Search the reflogs" in @Cascabel 's answer. As pointed out by VonC , the only real way to preserve this information is if your workflow includes saving it in a git note or annotated tag for each merge. – Yitz Apr 19 '20 at 09:40
  • 3
    This does not work correctly. In some project, I have done all my commits in master, but this `git name-rev` command on my commits gives branches I have never used, in particular remote branches from another user. This makes no sense at all! – vinc17 Jun 12 '20 at 10:58
  • 1
    In my tests this command only shows one branch. For a commit with 3 branches attached, the -a --contains option lists all three. – Cameron McKenzie Aug 05 '20 at 13:14
  • 1
    It would be helpful if you explained what this actually does. – Richard Hunter Apr 12 '21 at 01:22
  • This doesn't work for me, I am getting an unmerged dev branch as the result, even though the result should be the master branch. – Cole Apr 26 '21 at 04:50
  • This doesn't work in this scenario: I have a branch `A` and checkout branch `B` from it. The `HEAD` commit of `B` gives `name-rev` as `B` instead of `A`. – Leponzo May 04 '21 at 13:29
48

Update December 2013:

sschuberth comments

git-what-branch (Perl script, see below) does not seem to be maintained anymore. git-when-merged is an alternative written in Python that's working very well for me.

It is based on "Find merge commit which include a specific commit".

git when-merged [OPTIONS] COMMIT [BRANCH...]

Find when a commit was merged into one or more branches.
Find the merge commit that brought COMMIT into the specified BRANCH(es).

Specifically, look for the oldest commit on the first-parent history of BRANCH that contains the COMMIT as an ancestor.


Original answer September 2010:

Sebastien Douche just twitted (16 minutes before this SO answer):

git-what-branch: Discover what branch a commit is on, or how it got to a named branch

This is a Perl script from Seth Robertson that seems very interesting:

SYNOPSIS

git-what-branch [--allref] [--all] [--topo-order | --date-order ]
[--quiet] [--reference-branch=branchname] [--reference=reference]
<commit-hash/tag>...

OVERVIEW

Tell us (by default) the earliest causal path of commits and merges to cause the requested commit got onto a named branch. If a commit was made directly on a named branch, that obviously is the earliest path.

By earliest causal path, we mean the path which merged into a named branch the earliest, by commit time (unless --topo-order is specified).

PERFORMANCE

If many branches (e.g. hundreds) contain the commit, the system may take a long time (for a particular commit in the Linux tree, it took 8 second to explore a branch, but there were over 200 candidate branches) to track down the path to each commit.
Selection of a particular --reference-branch --reference tag to examine will be hundreds of times faster (if you have hundreds of candidate branches).

EXAMPLES

 # git-what-branch --all 1f9c381fa3e0b9b9042e310c69df87eaf9b46ea4
 1f9c381fa3e0b9b9042e310c69df87eaf9b46ea4 first merged onto master using the following minimal temporal path:
   v2.6.12-rc3-450-g1f9c381 merged up at v2.6.12-rc3-590-gbfd4bda (Thu May  5 08:59:37 2005)
   v2.6.12-rc3-590-gbfd4bda merged up at v2.6.12-rc3-461-g84e48b6 (Tue May  3 18:27:24 2005)
   v2.6.12-rc3-461-g84e48b6 is on master
   v2.6.12-rc3-461-g84e48b6 is on v2.6.12-n
   [...]

This program does not take into account the effects of cherry-picking the commit of interest, only merge operations.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • 4
    `git-what-branch` does not seem to be maintained anymore. [git-when-merged](https://github.com/mhagger/git-when-merged) is an alternative written in Python that's working very well for me. – sschuberth Dec 06 '13 at 14:37
  • @sschuberth thank you for this update. I have included your comment in the answer for more visibility. – VonC Dec 06 '13 at 14:52
44

For example, to find that c0118fa commit came from redesign_interactions:

* ccfd449 (HEAD -> develop) Require to return undef if no digits found
*   93dd5ff Merge pull request #4 from KES777/clean_api
|\
| * 39d82d1 Fix tc0118faests for debugging debugger internals
| * ed67179 Move &push_frame out of core
| * 2fd84b5 Do not lose info about call point
| * 3ab09a2 Improve debugger output: Show info about emitted events
| *   a435005 Merge branch 'redesign_interactions' into clean_api
| |\
| | * a06cc29 Code comments
| | * d5d6266 Remove copy/paste code
| | * c0118fa Allow command to choose how continue interaction
| | * 19cb534 Emit &interact event

You should run:

git log c0118fa..HEAD --ancestry-path --merges

And scroll down to find last merge commit. Which is:

commit a435005445a6752dfe788b8d994e155b3cd9778f
Merge: 0953cac a06cc29
Author: Eugen Konkov
Date:   Sat Oct 1 00:54:18 2016 +0300

    Merge branch 'redesign_interactions' into clean_api

Update

Or just one command:

git log c0118fa..HEAD --ancestry-path --merges --oneline --color | tail -n 1
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Eugen Konkov
  • 15,716
  • 7
  • 69
  • 107
  • 6
    This was the only solution that gave me the desired result. I tried the rest. – crafter Dec 15 '16 at 13:49
  • Note this only works if the merge commit summaries contain the branch names used in the merges, which by default they usually do. However `git merge -m"Any String Here"` will obscure the source and target branch information. – qneill Jan 23 '18 at 22:58
  • @qneill: No, the merge always has info about merged branches: `Merge: f6b70fa d58bdcb`. You can name your merge commit as you with. I will not have matter – Eugen Konkov Jan 24 '18 at 07:27
  • 1
    @EugenKonkov once the branches have traversed the merge, the history about which path in the graph they came from is left in the reflog, but not in the git object database. I posted an answer trying to explain what I'm saying – qneill Jan 26 '18 at 21:31
  • UPD version works for me, simple command that finds the original commit – vpalmu Apr 09 '18 at 10:42
  • In the UPD, what is or where does the hash "56a44a5" come from? – lordhog Oct 02 '18 at 21:54
  • @lordhog: Thanks. Fixed. In the UPD the `56a44a5` is HASH of commit you want to find. At this example we are looking for `c0118fa` – Eugen Konkov Oct 03 '18 at 05:42
13

khichar.anil covered most of this in his answer.

I am just adding the flag that will remove the tags from the revision names list. This gives us:

git name-rev --name-only --exclude=tags/* $SHA
phyatt
  • 16,890
  • 3
  • 51
  • 70
10

git branch --contains <ref> is the most obvious "porcelain" command to do this. If you want to do something similar with only "plumbing" commands:

COMMIT=$(git rev-parse <ref>) # expands hash if needed
for BRANCH in $(git for-each-ref --format "%(refname)" refs/heads); do
  if $(git rev-list $BRANCH | fgrep -q $COMMIT); then
    echo $BRANCH
  fi
done

(crosspost from this SO answer)

Community
  • 1
  • 1
Jeff Bowman
  • 74,544
  • 12
  • 183
  • 213
5

I deal with the same problem (Jenkins multibranch pipeline) - having only commit information and trying to find a branch name where this commit originally came from. It must work for remote branches, local copies are not available.

This is what I work with:

git rev-parse HEAD | xargs git name-rev

Optionally you can strip the output:

git rev-parse HEAD | xargs git name-rev | cut -d' ' -f2 | sed 's/remotes\/origin\///g'
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
miro
  • 71
  • 1
  • 6
4

A poor man's option is to use the tool tig1 on HEAD, search for the commit, and then visually follow the line from that commit back up until a merge commit is seen. The default merge message should specify what branch is getting merged to where :)

1 Tig is an ncurses-based text-mode interface for Git. It functions mainly as a Git repository browser, but it can also assist in staging changes for commit at chunk level and act as a pager for output from various Git commands.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
user1338062
  • 9,351
  • 3
  • 54
  • 56
3

As an experiment, I made a post-commit hook that stores information about the currently checked out branch in the commit metadata. I also slightly modified gitk to show that information.

You can check it out here: https://github.com/pajp/branch-info-commits

pajp
  • 486
  • 2
  • 4
  • 1
    But if you want to add metadata, why not using git notes, instead of messing with the headers of commits? See http://stackoverflow.com/questions/5212957/how-to-change-git-commit-message-without-changing-commit-hash/5213110#5213110, http://stackoverflow.com/questions/7298749/is-there-a-way-to-gracefully-change-a-git-branchs-history-when-forks-of-it-exis/7299044#7299044 or http://stackoverflow.com/questions/7101158/is-git-notes-the-intended-way-to-add-category-style-information-to-a-commit/7102923#7102923 – VonC Feb 14 '12 at 09:42
  • To be honest, I didn't know git notes existed when I wrote that. Yes, using git notes to achieve the same thing is probably a better idea. – pajp Feb 19 '12 at 17:58
2

TL;DR:

Use the below if you care about shell exit statuses:

  • branch-current - the current branch's name
  • branch-names - clean branch names (one per line)
  • branch-name - Ensure that only one branch is returned from branch-names

Both branch-name and branch-names accept a commit as the argument, and default to HEAD if none is given.


Aliases useful in scripting

branch-current = "symbolic-ref --short HEAD"  # https://stackoverflow.com/a/19585361/5353461
branch-names = !"[ -z \"$1\" ] && git branch-current 2>/dev/null || git branch --format='%(refname:short)' --contains \"${1:-HEAD}\" #"  # https://stackoverflow.com/a/19585361/5353461
branch-name = !"br=$(git branch-names \"$1\") && case \"$br\" in *$'\\n'*) printf \"Multiple branches:\\n%s\" \"$br\">&2; exit 1;; esac; echo \"$br\" #"

Commit only reachable from only one branch

% git branch-name eae13ea
master
% echo $?
0
  • Output is to STDOUT
  • Exit value is 0.

Commit reachable from multiple branches

% git branch-name 4bc6188
Multiple branches:
attempt-extract
master%
% echo $?
1
  • Output is to STDERR
  • The exit value is 1.

Because of the exit status, these can be safely built upon. For example, to get the remote used for fetching:

remote-fetch = !"branch=$(git branch-name \"$1\") && git config branch.\"$branch\".remote || echo origin #"
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Tom Hale
  • 25,410
  • 16
  • 132
  • 172
  • I had to google what reachable means, and what I found was that the commit is reachable if it is reachable in following the parent links, For me this was lightbulb moment as I initially had thought if its a tree structure, then all nodes are reachable if you can go any direction, this is not the case its a parent only direction - someone please correct me if I'm wrong – Max Carroll Apr 08 '21 at 09:44
1

I think someone should face the same problem that can't find out the branch, although it actually exists in one branch.

You'd better pull all first:

git pull --all

Then do the branch search:

git name-rev <SHA>

or:

git branch --contains <SHA>
Yates Zhou
  • 43
  • 4
0

If the OP is trying to determine the history that was traversed by a branch when a particular commit was created ("find out what branch a commit comes from given its SHA-1 hash value"), then without the reflog there aren't any records in the Git object database that shows what named branch was bound to what commit history.

(I posted this as an answer in reply to a comment.)

Hopefully this script illustrates my point:

rm -rf /tmp/r1 /tmp/r2; mkdir /tmp/r1; cd /tmp/r1
git init; git config user.name n; git config user.email e@x.io
git commit -m"empty" --allow-empty; git branch -m b1; git branch b2
git checkout b1; touch f1; git add f1; git commit -m"Add f1"
git checkout b2; touch f2; git add f2; git commit -m"Add f2"
git merge -m"merge branches" b1; git checkout b1; git merge b2
git clone /tmp/r1 /tmp/r2; cd /tmp/r2; git fetch origin b2:b2
set -x;
cd /tmp/r1; git log --oneline --graph --decorate; git reflog b1; git reflog b2;
cd /tmp/r2; git log --oneline --graph --decorate; git reflog b1; git reflog b2;

The output shows the lack of any way to know whether the commit with 'Add f1' came from branch b1 or b2 from the remote clone /tmp/r2.

(Last lines of the output here)

+ cd /tmp/r1
+ git log --oneline --graph --decorate
*   f0c707d (HEAD, b2, b1) merge branches
|\
| * 086c9ce Add f1
* | 80c10e5 Add f2
|/
* 18feb84 empty
+ git reflog b1
f0c707d b1@{0}: merge b2: Fast-forward
086c9ce b1@{1}: commit: Add f1
18feb84 b1@{2}: Branch: renamed refs/heads/master to refs/heads/b1
18feb84 b1@{3}: commit (initial): empty
+ git reflog b2
f0c707d b2@{0}: merge b1: Merge made by the 'recursive' strategy.
80c10e5 b2@{1}: commit: Add f2
18feb84 b2@{2}: branch: Created from b1
+ cd /tmp/r2
+ git log --oneline --graph --decorate
*   f0c707d (HEAD, origin/b2, origin/b1, origin/HEAD, b2, b1) merge branches
|\
| * 086c9ce Add f1
* | 80c10e5 Add f2
|/
* 18feb84 empty
+ git reflog b1
f0c707d b1@{0}: clone: from /tmp/r1
+ git reflog b2
f0c707d b2@{0}: fetch origin b2:b2: storing head
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
qneill
  • 1,451
  • 12
  • 15
  • And what is the output for `git log 80c10e5..HEAD --ancestry-path --merges --oneline --color | tail -n 1` and `git log 086c9ce..HEAD --ancestry-path --merges --oneline --color | tail -n 1` commands for both cases? – Eugen Konkov Jan 27 '18 at 00:08
  • The SHAs of course change any time the commands are run, to respell your commands I used **HEAD^1** and **HEAD^2** on a fresh run. The commands and output are: `$ git log HEAD^1..HEAD --ancestry-path --merges --oneline --color | tail -n 1` which yields `376142d merge branches` and `$ git log HEAD^2..HEAD --ancestry-path --merges --oneline --color | tail -n 1` which yields `376142d merge branches` -- which shows the merge commit summary, which (as I was asserting) can be overwritten when the merge is created, possibly obfuscating the branch history of the merge. – qneill Feb 02 '18 at 15:42
0

I tried all of the above solutions, and none of them quite worked for me.

Here is the only method that has worked for me so far (assuming HEAD is in a sensible place):

git log --branches --source | grep <sha>

#or if you also care about remotes
git log --branches --remotes --source | grep <sha>

The name of the branch should be at the end of the line.

From the documentation

--source

Print out the ref name given on the command line by which each commit was reached.

So this may change depending on where HEAD is, but for me putting HEAD at the latest commit on my master branch produced the results I expected.

Visual inspection with gitk --all may also be helpful. It has a 'branches' field for each commit, but it shows all branches that "can reach" that commit, not necessarily which branch that commit is "on". See here

Cole
  • 244
  • 2
  • 7
-1

To find the local branch:

grep -lR YOUR_COMMIT .git/refs/heads | sed 's/.git\/refs\/heads\///g'

To find the remote branch:

grep -lR $commit .git/refs/remotes | sed 's/.git\/refs\/remotes\///g'
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Gary Lyn
  • 1,078
  • 8
  • 11
-4

Aside from searching through all of the tree until you find a matching hash, no.

Amber
  • 446,318
  • 77
  • 595
  • 531
  • 7
    I don't really want to downvote this, because strictly speaking it's true that git doesn't permanently store that information, but it is very often possible to find out nonetheless. See my answer. – Cascabel Apr 25 '10 at 04:09