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/hooks/: No such file or directory protocol error: expected control record on Mac osx
  • Private git repository over http
  • git push to different branches on multiple remotes
  • files that have not been changed show up in unstaged list after git stash
  • With git, temporary exclude a changed tracked file from commit in command line
  • List all files that are not ignored by .gitignore
  • 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.

  • How to deploy a plugin to Jenkins Hosting?
  • How do you hide .git project directories?
  • git filter-branch with --subdirectory-filter removes all files
  • Sunspot Solr Gem & .gitignore
  • Count commits on one branch not on another
  • Revert and unstage
  • 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.