2 possible reasons for this:
If that doesn't help, please post more detail on the exact setup you have.
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.
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.
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.
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.
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.
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.
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).
The graph displays a straight blue line with dots, even though the last three commits were on a branch.
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.
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.
Hello Sourcetree users!!! With the recent removal of Bitbucket Cloud account passwords for app passwords (please see our Bitbucket Cloud community post for details on why we made this change for se...