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:

  • File not shown in git diff after a git add. How do I know it will be committed?
  • git how to clean a cloned repository and reclone
  • How do I remove Tag in GitLab repository
  • Arrows direction in ProGit book
  • Powerful gitk/gitg alternative?
  • Releasing multiple Maven artifacts when using nested Git submodules
  • 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.

  • Git create branch from range of previous commits?
  • how should the other remote site using gerrit server based on a mirror repo?
  • Git repository size is larger than it should be
  • Is there a way to easily convert a series of tarballs of a source tree into a git repository?
  • How can I give read Access to everybody with gitolite
  • Forcing a merge after git fetch
  • 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.