The parental relationship between commits is what gives a repository its "structure". And a visualization like the one displayed on the Git Flow website is definitely possible with Git. It was designed around Git!
Here is an example that should get you started:
First, create a new repository and add a single empty commit:
$ mkdir test-repo && cd test-repo $ git init $ git commit --allow-empty -m "Initial empty commit"
At this point you've got one branch and one commit. Your network will look something like
[master] A
Here,
A
represents the blue dot at the extreme top-right corner of the Git-Flow site.This commit is missing its tag from the diagram. Let's add it:
$ git tag -a 0.1
Now we've got
[master] [0.1] A
Now we'll create our
develop
branch:$ git checkout -b develop
At this point, we haven't added any commits to
develop
that aren't inmaster
, so the branches are pointing to the exact same commit:[master] [develop] [0.1] A
It's getting a bit crowded here. Let's add a few more commits to
develop
:$ # Hack, hack, hack... $ git add somefile.txt otherfile.dat $ git commit $ # Hack, hack, hack... $ git add foo.bar $ git commit
Now our network is a little bit more interesting. When we created each of these two new commits, our
develop
branch was updated to point to each of them in turn. Now we've got[master] [0.1] A \ [develop] B---C
develop
actually points to commitC
at this point, and we can traceC
's ancestry back to commitA
.We can do the same thing with a new branch
issue22
, though it won't be nameddevelop/issue22
unless we explicitly call it that:$ git checkout -b issue22 $ # Hack, hack, hack... $ git add foo.bar $ git commit
and now we've got
[master] [0.1] A \ [develop] B---C \ [issue22] D
issue22
branches off ofdevelop
by virtue ofD
's parent beingC
. We can do some more work on bothdevelop
andissue22
[master] [0.1] A \ [develop] B---C---F---G \ [issue22] D---E---H
without changing that relationship. Then we can merge
issue22
back intodevelop
(or directly intomaster
, though that's not the "Git-FLow way") and get something like[master] [0.1] A \ [develop] B---C---F---G---I \ / [issue22] D---E---H
This model extends to as many branches as you'd like, and with a little care you could exactly reproduce the Git-Flow diagram. Branches don't "diverge" until they contain different commits.
It might be helpful for you to understand a little bit about Git's internal workings. The website Think like (a) Git is a very good introduction.