How can I find out the git branch my current branch is based on?

It might be a simple question (maybe asked before?), But I couldn't find an answer. (I've really tried, I'm not just lazy :))

I am working on a git branch based on another branch. However, I don't know which branch it is based on.

Is there a command or way to find out which branch my current branch is coming from?

I tried looking in SourceTree and also with "git log -graph -all", but somehow I can't figure out the starting point when the branch was created.

Thank!

+3


source to share


2 answers


In fact, there is no such thing in git.

This is perhaps best illustrated by an example. Consider the following snippet of the commit graph:

        o    <-- branchA
       /
o--o--o
    \
     o--o    <-- branchB

      

Here "obviously" branchB

comes from branchA

. But wait, there is still, there I forgot a little:

        o    <-- branchA
       /
o--o--o--o   <-- branchC
    \
     o--o    <-- branchB

      

Now, branchB

shutting down branchA

or shutting down branchC

?

The trickiest part is that any of these branches can be created in any order: 1 and in addition, the branch names can also be moved or deleted at any time. 2 So, if you decide it is branchB

"based on off" branchA

, but then someone removes completely branchA

, you are left with this:



o--o--o--o   <-- branchC
    \
     o--o    <-- branchB

      

and now branchB

clearly relies on branchC

rather than branchA

.

[ Edit : if you want to define a specific commit when the two branches are split at first, use git merge-base

. By finding that commit, you can see that other branch names might also be interesting with git branch --contains

and so on. The general rule of thumb here is that the commit graph is all you really have: labels like branch names are only good until you or someone else change them later. Tag labels should generally stay where they are, but even those that can be moved are just more painful.]


1 Well, pretty much everything: the parent commit of a new commit must exist before you can create child commits, unless you have a way to crack the cryptographic SHA-1 hash.

2 Removing a tag means that commits found starting at that tag and working "backwards" (left and up, or up or down and as long as you keep moving left) into those pictures) become "inaccessible" unless they are found. starting with some other label. The unreachable commits in the commit graph eventually 3 are completely removed, but you usually have about 30 days to get them back.

3 This is accomplished with git "reflogs". Each reflog entry acts like a normal shortcut in terms of making the "reachable" and therefore saving it. These are actually log entries that have expired.

+5


source


Unless git -gc (1) has removed or removed the information, create a shell script in your $ PATH, call it git-fork-point

like this:

#!/bin/sh

if [ $# -gt 0 ]
then
    target="$1"
else
    target=$(git branch|sed -ne 's,^\* ,,p')
fi

git reflog |sed -nE \
    "s,^([a-f0-9]+).*: checkout: moving from ([^[:space:]]+) to ${target}\$,Forked on commit \1 from \2.,p" |tail -1

      

It can now be used as a git fork-point and defaults to the current branch.

This is based on the assumption that the first occurrence of a branch name associated with a checkout creates a new branch (reflog is in reverse chronological order, hence tail -1).



There is something wrong:

  • reusing the branch name after detecting that the wrong parent is being used is indeed listing the wrong parent
  • If no history is provided, it is just a list on first launch.

It only works 80%, which is why I use it.

0


source







All Articles