Ways to clean up version tree/branches

tim_hess427

I want to get some feedback from the community on this issue. Maybe we need to adjust our workflow. I've got a fairly large document with a couple dozen parts and we've been trying to follow a GIT workflow where we create branches for design changes. Once we're happy with the changes, we merge back into our development branch. Then, we repeat for the next design changes by creating a new branch for a new set of changes.

This seems to work OK, but it has resulted in a really large number of branches. So, when I open the version tree, the formatting of the branches makes it difficult to see where the most recent work is being done. This is made worse when an update is pushed to the document and any open workspaces are pushed to the top of the tree with no real design changes being made. It would be great if I could make the version tree wider so that I can see more branches at one time.

So...

1.  Can/should we be doing something different with our workflow to keep things more clear? I've thought about separating parts into separate documents, but I've read that each document should be a container for a whole project.
   
2. Would others find value in a full-screen, or adjustable width version tree view? I'm thinking this could be an improvement request.
   

mthiesmeyer

Hi @tim_hess427,

If you are not creating versions on your "development" branches then you can delete the workspace once you have finished merging it in. This is very much like a git workflow where you branch -> edit -> merge -> delete branch.

Best,

Mike

adrian_vlzkz

So you are not working on the main Workspace for design at all?

Haven't used Branch much, but our intention would be to use them for alternate design option, a concept that is somewhat different from the main intent of the design. I believe the Main should still be used for linear development of the design, not just as a placeholder for Merges

mthiesmeyer

Hi @tim_hess427,

If you are not creating versions on your "development" branches then you can delete the workspace once you have finished merging it in. This is very much like a git workflow where you branch -> edit -> merge -> delete branch.

Best,

Mike

tim_hess427

@mthiesmeyer - If we don't create a version on the branch, does the whole branch disappear when the workspace is deleted?  What happens to all of the micro-versions created on the branch? Are they lost too?

@adrian_velazquez - Correct (for the moment at least). This method makes it clear where the released parts can be found are (Main) and which design changes are just experimentation and exploration.  However, we're still trying to figure out the best workflow and open to trying new approaches.

In your situation (using branches for alternate design options) I would worry about a shared feature between the different design option not appearing on every branch that needs it. Although, I suppose the two methods are not mutually exclusive. There could be "Main" branches for each alternative design option, with development branches coming off of those. 

adrian_vlzkz

I'm just not married with the idea of using Branches for more purposes, since you're duplicating the entire document. I love the idea of branching if it was at the Object or at-least element (Tab) level. Even thought in Onshape your are not "copying files", you are still creating duplicates in your environment (they are searchable.

In this example, I created Branch B1 to work on the assembly (Assembly 1), but  Part Studio 1 also has a B1 instance, to me that is just clutter...  since I did not touch it.




This is the simplest of scenarios, real world situation this would be exponential, with larger documents, more versions, and more users doing it.


And to you can delete the active workspace of a branch w/o deleting saved versions in that branch

billy2

As long as the branch has no versions, the branch can be deleted. If the branch has a version, then it can't be deleted. It can only be deleted to the version in the branch.

In your workflow, you'll want to not version a branch. May be easier said than done.

mlaflecheCAD

Here are three examples of the GIT workflow in Onshape.

1.  A simplified GIT workflow that allows work to be done on the main branch and ideas can be carried out on separate branches.  Versions can also be set on the branches so that if a branch is deleted, it essentially closes the branch (As shown on branch B2.1 - Cover) . 

Here is a link to the document:  https://cad.onshape.com/documents/adf65b4c7870a25d7c4cf02d/w/aa3e050d083b4e92fb768569/e/62d8dda31a47fd17b1657f45

2.  A stricter more classical version of the GIT workflow where no work is done on the main branch.  There is a technical article in our learning platform that describes this method in detail:  https://learn.onshape.com/learn/article/gitflow-version-management.  

And a link to a document can be viewed here:  https://cad.onshape.com/documents/d8f2d0a4fb7dbdc8e25543f9/w/bb178dbccdcf543beac3e3fb/e/69732de7432660fad839d4a2


3.  A GIT branched workflow where work can be done on the "Main" branch but "Releases" are applied at specific points in time on the Main branch and ECO's (Change Orders) are proposed on branches from the versions.   Certain parts and drawings are submitted for "Release" along the way.



I hope this helps!

tim_hess427

Thanks for the information @mlaflecheCAD! The last screenshot is interesting to me. To create that version tree, I'm assuming changes from B2 and B1 were merged back into Main for between each of the releases. Is that right? One thing I've thought about, is that it would be nice to have a visual for "merges" similar to the branches. If I were to just look at that diagram, I would have no idea what work was done where (except something must have changed on B1 and B2 after ECO-000923-B).

I think I've been following the process from #2. But it has just gotten so big due to the number of revisions and components in our document. It has become difficult to understand what's changed (and where).

Do you have recommendations on when it makes sense to move parts to separate documents vs keeping them in one document? At the moment, I've got all the parts for one top-level product assembly in one document.

mlaflecheCAD

Hi @tim_hess427 thanks.  The merge operation will show as a microversion in the the history.  If merged from just the branch it will just put the branch name in, and if merging from a version on the branch it shows that specifically.  If you would like a graphical merge line back in, please feel free to submit a support ticket for that.  


  

Also on the topic of separate linked documents. Here is my decision tree:

1.  How do I share the data with suppliers and customers.  (Sharing happens per document)
2.  Do I want a separate version history for some of the items in my design?  (Version history is per document, revision treatment is per item within the document)
3.  Are there parts that are "Library" items that are used on across many products? (It may be easier for users to discover items maintained in a library in a folder)

If the parts have no geometric relationship to one another, then I will create that as a separate document.

Here is a view into my document structure for the Coffee Grinder
The folder my unique documents for the coffee grinder live in.





My library folder, where some of the parts in my coffee grinder live.


And finally the BOM structure view, showing is on one list of the right.

adrian_vlzkz

+1 on the Visual indicator for Merges, another good option to do a Merge and Close Branch (Combining two steps).

tim_hess427

@mlaflecheCAD - Thanks for the tips!

I see that for branch management, I have two options - leaving the branches by creating versions on them and deleting the workspace (if appropriate) or I could just merge and delete the branch without creating a version.  I'm not sure I like the idea of deleting the branch entirely, as I think it could be useful to see the history of the branch being created, work being done, and then merged back in. I'm torn between keeping all of the information available and cleaning things up.

This discussion has been very, helpful, though.

brucebartlett

Great discussions here. I also find it annoying that the branches advance after an update which loses the visual map of where the last work was done.  I have run into problems with far too complex version graphs which become un-usable for myself and would be impossible for anyone else to come in and try to figure it out. My advice would be to keep the branches small and logical based on the need at the time and named well and pruned to get rid confusion. 

@mlaflecheCADmlaflecheCAD said:

Also on the topic of separate linked documents. Here is my decision tree:

1.  How do I share the data with suppliers and customers.  (Sharing happens per document)
2.  Do I want a separate version history for some of the items in my design?  (Version history is per document, revision treatment is per item within the document)
3.  Are there parts that are "Library" items that are used on across many products? (It may be easier for users to discover items maintained in a library in a folder)

If the parts have no geometric relationship to one another, then I will create that as a separate document.

Michael, this is great advice but I find the first consideration, sharing data with suppliers, I often do not consider this at the start of the design process as I sometimes don't know what process will be, so when it gets to share data with suppliers for quotes/manufacturing advice, items have been embedded into a document which can't be shared in total, I'd love a way to share more gradually from within doc without sharing everything. At the moment my best solution has been to just save things out and share by traditional means. 

mlaflecheCAD

@brucebartlett great points on data sharing.  ;-)