SourceTree graph does not show branches

[richardlent]

I have a couple of branches in my SourceTree repository but the graph (Mac) is always straight and does not show any branches.

[stevestreeting · Accepted solution]

2 possible reasons for this:

1. You have 'Current Branch' selected at the top of the log view, or
2. The branches didn't actually cause a divergence in the graph. A branch is just a marker, unless different commits actually occurred in each that were not shared between then, there won't be a fork in the graph.

If that doesn't help, please post more detail on the exact setup you have.

[Jesse Seger]

Can you elaborate on item number 2 just a bit?

[Jesse Seger]

Nevermind. I think I got it.

There aren't any new changes on the main branch.

[Shelli]

I am having this issue and neither case 1 nor 2 apply. If I view the graph in TortoiseHg, I see the divergence in the graph. Why doesn't Sourcetree show it?

[Shelli]

I have found that the graph shows the divergence only after a change is made to the main branch.

[Darko Damjanovic]

I would really like an option to see the fork visually even if there is no real divergence. It would be so much easier to understand what is going on. I know that the graph could expand quite a bit to the right sometimes with this option turned on but if you do not like it you could just turn it off. Please search for "clearcase version tree" in the Google images search and see the most intuitive graph view of all version control system. Thanks.

[CrazyTim]

I would also like to see the graph always diverge - at least add it as a setting . Its confusing to get your head around how it works.

[asimsuvedi]

select-all_bramches.PNG

You just need to select All branches and it'll show the all branches. In my case I created a new branch named Sprint 19 from master, did commits to Sprint 19 and also had a commit to master branches after the commits on sprint 19. 

[kevinruess]

Another possibility for those struggling out there might be that you have the date column set to Ancestor Order instead of Date Order

Nevermind - I think I'm wrong in this statement

[Brian Yeh]

This is bad UI. You don't need to see an artificial fork but you should be able to see that the two branches are pointing to the same node. Right now if I create a new branch from one node, there is no way of knowing from the GUI if I'm on the old branch or the new branch. The GUI just tells you that you've checked out the node and that the branch is the original branch you were on, with no mention of the new branch that was created. 

[Lawrence Dol]

As far as I'm concerned, this is a huge usability bug.

The graph should always show branches as branching. Moreover, it should make an effort to ensure branches maintain the same color and left-to-right place in the history. It's horribly confusing that develop and master keep switching places and colors.

[sachelis]

I agree! If there is a branch, it should be shown. It seems bizarre that branches aren't displayed until the master branch "grows" (i.e., has a commit).

[Chris Edwards]

I agree too - it is very confusing for a developer if they make a branch from a branch, so that all their branches are in a chain. The GUI will imply that they are still on the Master branch, which is completely incorrect, and the developer will need to read back through the git history to see each branch. Certainly the developer can do that - but that's the exact same way they would do it when using a Git console. We use SourceTree because we do not want to use the pure console, we want visual representations of things such as branches.

The default behavior should be to show that branches actually branch; but that's not even an option. This is bad GUI design. 

[DarkoDamjanovic]

I understand that the current way of visualising the branch history is kinda the "accepted" way in the git community. Basically because it's also the way the git command line tool shows the history. Nevertheless I think the suggested style of visually branching (even if there is no divergence) could be accepted quite quick because it is way more intuitive to understand. And it will not be a risk for SourceTree if it is an option and not the default - so the user could activate and deactivate it on demand. I would like to hear at least a response from Atlassian if this is considered at all - so at least we do not loose our time anymore here if not. Thanks.

[sachelis]

Agreed, Darko. knew I was awakening an old thread, but that seemed more appropriate than starting a new one. I expect it's doubtful this will be implemented, but thought it was best to speak up.

[bdbolin]

Still like this in 2020. Totally agree it should visually show the difference.

[Chris Edwards]

You are correct and it may be the 'accepted' way because it's how the console does it - but we are using a program with a GUI specifically because we do not want to use the console. The GUI should take advantage of the fact that it has a GUI, and should show branches as branching. There is no reason for a GUI program to show things the same way as a console program when the GUI provides a better option.

[sachelis]

I agree the branch should be displayed even if the master branch hasn't been changed. The graph being a straight line (i.e., a blue line with dots) is confusing, at least to me, because it doesn't let me know there is a branch (and that I'm working on it).

For example:

1. Create a branch off the master.
2. Change a file. Stage, commit, and push it. Do this three times.

The graph displays a straight blue line with dots, even though the last three commits were on a branch.

Now:

1. Checkout the master branch (i.e., double click on it's name in the list of branches on the left).
2. Change a file. Stage, commit, and push it.

Now I can see that the first three commits were made to the branch and not the master. I think the branch should be visually represented (it is there) without needing to commit a change to the master.

[Hannes Holst]

I have this 'issue' too.
To be honest, I thought the whole time I did something wrong.
And, when you think you did something wrong in a software which you actually didn't - then, it is a bad software design.

[philmottin]

Found this topic, after searching for a similar problem on this subject.

I understand the sourcetree behavior about the graph only displaying the split after master has changed.

But then, how the graph on the 2nd picture attached was made? there is only 1 dot per brench/merge.

A normal branch flow with 1 commit on each master and brach, will result like the 1st picture.

I can't replicate this. Any ideas ?

[philmottin]

-

[conaperd]

Has anyone gotten an answer from Atlassian regarding this? I also find this totally non-intuitive, specially for first-timers.

[DarkoDamjanovic]

You can see here that branching is possible eve if the current root node stays the same:

The endpoint of one branch is then just the starting point of another. Git currently draws them as same (which is unintitive).

[DarkoDamjanovic]

@Asim Suvedi

No, thar youm id' something different. You describ a way to enable the lit view with the fie. We are askin for something totoally differemnt. Divveergence o brnached if uf there knoteda are on the same opsiiion.

[Alex]

Ola, eu fechei alguns ramos ficaram fechados mas  após a ultima atualização eles voltaram a aparecer para mim , gostaria de saber como faço eles sumirem do meu controle novamente e que fique só os ativos?

[Venod Raveendran]

SourceTreeBranchIssue.png

This is actually Window pane issue, we have to drag the edge of the file list Slowly to reveal the Branch list.

It was very annoying and I tried all the option, then it clicked me that it may be hidden behind the file list.

If you move the mouse near the edge of this files list Cursor will change to <-> now try dragging towards right and you could see the Branch list.

[asimsuvedi]

select-all_bramches.PNG

You just need to select All branches and it'll show the all branches. In my case I created a new branch named Sprint 19 from master, did commits to Sprint 19 and also had a commit to master branches after the commits on sprint 19.