Sourcetree graph - master vs develop

sho-87

I've only just started using git and I'm confused by the sourcetree graph

As a newcomer to git, this outline here seems to be very logical: http://nvie.com/posts/a-successful-git-branching-model/

That would suggest I have a master branch with stable and deployable code, and a parallel develop branch where I can fix things/add features

Turns out that git flow in source tree supports the same type of layout. For example, if you choose to add a new feature, it gets added to the develop branch instead of the master branch

This all makes sense to me, but this isn't really reflected in how the graph is displayed

I've spent the last few hours trying to figure out why the graph in sourcetree is straight/linear despite using git flow to create a develop branch, as well as features off of that branch

It turns out that even if I add features to develop, no branching will occur in the graph unless I make a commit to master that does not exist in develop/any other branch

This seems backwards to me and doesn't fit with the layout in the site listed above, or the layout adopted by git flow. In order to get branching in the graph, I need to make changes to master that are different from develop. Doesn't it make more sense that I should make commits to develop that don't exist in master? (i.e. the other way around?)

Am I just fundamentally misunderstanding git? In my mind I should be making constant commits, features additions in the develop branch, and then merging back into master. But it seems the only way to get graph branching is to make those constant commits in master instead (and then merge into develop?...)

Tim Crall1

To follow up on what the others have said:

 

Yes, you should commit to the develop branch and then merge to the master branch.  Actually, if you're following full Git Flow, you should commit to feature branches, merge to the develop branch, do integration testing and making any necessary integration fixes, and then merge to the master branch (or maybe to a release branch and then the master branch).

But that's all part of "Git Flow" and not enforced by Git.  It's just a work flow (and only one of several out there - see for instance GitHub Flow which is probably beginning to surpass it in popularity).

 

SourceTree doesn't show a divergence when you commit to a branch because the two lines of development haven't really branched off - one has just gone ahead.  Unless a commit is made on the master branch - either directly or by merging another branch in the meanwhile - the repo's history is still linear, with every commit having only one parent commit.  In fact, if that's still the case when you go to merge, Git/SourceTree will by default perform a "fast forward" merge in which the "master" branch label is just moved to the tip of the develop branch, and the history will still look linear. It's common in Git Flow to turn that feature off so that merge commits are always created (even though they're technically unnecessary).

Basically GitFlow diagrams are designed to show a conceptual understanding that is useful conceptually but the SourceTree diagram is a little closer to showing what is actually happening in Git.

From the point of view of the directed acyclic graph (dag) that is at the heart of Git's data structure, there is no difference between 

Screen Shot 2016-04-04 at 12.34.46 PM.png

and

Screen Shot 2016-04-04 at 12.36.11 PM.png

and git shows it the first way

 

 

Screen Shot 2016-04-04 at 12.36.11 PM.png

Screen Shot 2016-04-04 at 12.34.46 PM.png