Does branching in git create a parent-child relationship?

If I do

$ git branch a
$ git checkout a
Switched to branch 'a'
$ git branch b
$ git checkout b
Switched to branch 'b'
$ git branch c1
$ git branch c2

Is there any relationship between these branches, or are there all considered ‘flat’ because there weren’t any commits in them? In SVN, I would model these branches like this:

  • Git branches with completely different content
  • How do I squelch “fatal: The upstream branch of your current branch does not match the name of your current branch”?
  • Should I use git to deploy websites?
  • git extensions for visual studio - how to revert a single file to earlier commit
  • Possible to clone TFS project with Android Studio
  • How to update posh-git
  • master
    |
    +-a
      |
      +-b
        |
        +-c1
        |
        +-c2
    

    However, when I try to follow this question and do gitk master a b c1 c2, I get a flat line, not the diagram I put above.

  • Explanation of “overwrting local changes” warning when switching branch in git in this scenario?
  • Stuck repo using stash after crlf normalization?
  • Heroku app seems to be pulling from wrong Git respository/branch
  • git aws.push: 'aws.push' is not a git command
  • Git Extensions: Win32 error 487: Couldn't reserve space for cygwin's heap, Win32 error 0
  • git ignore .env files not working
  • 4 Solutions collect form web for “Does branching in git create a parent-child relationship?”

    git doesn’t have a strict parent branch, it just has a particular commit path. In this case, they all have the same commit as their starting point, so they’re all the same. As soon as they start having their own commits, they’ll be their own “lines”, but they won’t really have a relationship to one-another.

    At any point though you can easily merge with any branch using git merge, so the “parent” relationship isn’t all that fundamental. Git does have the concept of a parent for the case of using --track (where you receive your parents commits), but this is just a special convenience function. You could easily have any number of “parents” if you dot your I’s and cross your T’s (git merge branch A, git merge branch B, etc).

    To me it is helpful to think of branches as pointers. You are starting out with a pointer called master that points at a particular commit. When you create a branch, you are just creating another pointer that is pointing at the same commit. So the set of commands you have above results in 5 pointers (master, a, b, c1, c2) that are all pointing at the same commit.

    There are no relation between branches.

    This instruction:

    git branch c1
    

    is equivalent to:

    cat .git/HEAD > .git/branch/ref/heads/c1
    

    So when creating a branch, you are only setting a key-value relation between the name of the branch and the commit identified by it’s SHA1.

    I believe if you merge with –no-ff it will not fast forward the changes and you will have a tree history exactly as it was created.

    Git Baby is a git and github fan, let's start git clone.