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?...)
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
Screen Shot 2016-04-04 at 12.36.11 PM.png
and git shows it the first way
The graphs in git flow are expressly designed to make the workflow it is describing perfectly clear. While SourceTree supports git flow, it doesn't require it. Furthermore, attempting to maintain a permanent horizontal position for each branch becomes a huge space waster (and probably nightmarish to implement) in larger, older projects. Here is a screenshot of part of my repository's graph (from months ago):
Supported Platforms macOS Sourcetree has a lot to offer and, like many developer tools, finding and using it all can be a challenge, especially for a new user. Everyone might not love ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot