Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Branching GUI doesn't feel intuitive
CaptainBisquick
OS Professional Posts: 33 ✭✭
I find the branching tools unintuitive and slightly confusing.
Let me give the disclaimer that I understand the practices of branching quite well. I work as a software developer, and I have fairly extensive experience with Git, and to a lesser degree, Subversion and CVS. I've performed an svn to git migration for a major website (a household brand name most people know), and I'm often able to help my colleagues in answering their git questions and provide git workflow solutions to problems when they come up.
That being said, I find branches in OnShape slightly obtuse.
https://www.dropbox.com/s/x13cbcsbtxu9qvb/Screenshot 2015-12-06 19.03.56.png?dl=0
First I have only Start and Main. I discover I must create v1 before I can create v2. At first this is confusing to me, but after more thought, I conclude that Main is analogous to unstaged changes, v1 is analogous to my first commit, and v2 is analogous to a branch created off that commit. After working through it, I can see the logic behind it, but not at first.
I feel like some slight changes could make the representation more intuitive. For example, I don't think I would include unstaged changes as a node in the tree. And since Start is also unstaged changes, I wouldn't include that either. When v1 is created, I would make that the first node. I think it would make more sense to not show any nodes on the graph at first. This would communicate to users that they haven't saved their changes to any branch, and so there is nothing yet for them to branch off of. I think this would also be more clear to people when they then see v1 – v2, and not Main in between v1 and v2, with Start below. Both Start and Main being some other kind of special node which doesn't have all the same privileges that versions have?
Also, why can I change to the start node? There is nothing in the scene at this point. In a code project, I can't change to a point before changes have been committed.
I hope this helps. Actually, writing it has really helped me understand how to use branches in OnShape
.
Let me give the disclaimer that I understand the practices of branching quite well. I work as a software developer, and I have fairly extensive experience with Git, and to a lesser degree, Subversion and CVS. I've performed an svn to git migration for a major website (a household brand name most people know), and I'm often able to help my colleagues in answering their git questions and provide git workflow solutions to problems when they come up.
That being said, I find branches in OnShape slightly obtuse.
https://www.dropbox.com/s/x13cbcsbtxu9qvb/Screenshot 2015-12-06 19.03.56.png?dl=0
First I have only Start and Main. I discover I must create v1 before I can create v2. At first this is confusing to me, but after more thought, I conclude that Main is analogous to unstaged changes, v1 is analogous to my first commit, and v2 is analogous to a branch created off that commit. After working through it, I can see the logic behind it, but not at first.
I feel like some slight changes could make the representation more intuitive. For example, I don't think I would include unstaged changes as a node in the tree. And since Start is also unstaged changes, I wouldn't include that either. When v1 is created, I would make that the first node. I think it would make more sense to not show any nodes on the graph at first. This would communicate to users that they haven't saved their changes to any branch, and so there is nothing yet for them to branch off of. I think this would also be more clear to people when they then see v1 – v2, and not Main in between v1 and v2, with Start below. Both Start and Main being some other kind of special node which doesn't have all the same privileges that versions have?
Also, why can I change to the start node? There is nothing in the scene at this point. In a code project, I can't change to a point before changes have been committed.
I hope this helps. Actually, writing it has really helped me understand how to use branches in OnShape
.2
Comments
Onshape document history -> git commits
Onshape branches -> git branches
Onshape saved versions -> git labels
Main -> HEAD of your master branch
And onshape only allows you to create new branches off saved versions. In most case 'Start' is empty unless the document is created with import geometry in which case it will have something meaningful to branch from.
There may be multiples of these open circles - one at the end of each branch - so that you can 'check out' any of those to do you your work, so that you have a space for your work. Indeed we call them workspaces :-)
Ilya Baran wrote a good blog post that includes some details on versions and branching: https://www.onshape.com/cad-blog/under-the-hood-collaboration