Branch and Merge

brucebartlett

Is anyone successfully using the branch and merge? Normally I keep clear of trying to merge 2 branches but this time they got away from me. With this project, I am collaborating with 2 other users and  I am trying to merge about 6 hrs of work together across various part studios and assemblies from 2 separate branches.  When merging all I seem to get is copies of the alternative branches and can not seem to find a method to retain the parts I want from each other. Keen to hear others experiences or solutions.  

coleman

Branching and merging can get messy. 
My guess is that user adoption of branching and merging is less than onshape expected.     

michael_bromley

We do successfully use it for initial concept generation, but you have to be careful to keep the branches under control.  As you have experienced it can get out of hand quickly if you go too far down the design route before trying to merge.  We use it more to experiment with new ideas prior to introducing it to the team ongoing development branch.  In this case we have little offshoots in many places to try something out and it is easily deleted or merged if necessary.

I believe it has been mentioned before, but some kind of selective merge would be very helpful in the situation that it sounds like you are in.  If you could pick and pull pieces/parts from different branches for a combined merge.  However, I can see this getting messy on OnShapes side of things as to where to make the cut for parts that reference others, etc.

lana

As implemented now use of brunching and merging requires some advanced planning. Please write an IR for easier to use merge  - it will help us to prioritize this project.

EricGauthier

Working fulltime in Onshape since March 2018, I can't figure out yet how to manage branching and merging in a useful way in my projects. /-:

mlaflecheCAD

@EricGauthier please take a look at the learning center article here, and let me know what you think.  The approach to successful branching and merging is several well defined branches without extreme or radical differences.  https://learn.onshape.com/learn/article/gitflow-version-management

brucebartlett

Hi @mlaflecheCAD & @EricGauthier , I have tried using a DEV branch as described in the link above and only having the main as a REL branch and have come to the conclusion after 3 or 4 projects it is easier just to work on the main branch and not worry about REL and DEV.

Here are a few reasons why I have switched back to just working on the main. 

• It is very easy to accidentally work on the node of the main branch when everything should be done on the dev. Especially with collaborators.
• Documents have to be set up at the start to avoid adding versions on the main branch. Easier just to start work and avoid versioning for as long as possible to keep tree clean.
• Branches including your DEV branch can be accidentally deleted losing your work
• Merge across to main sometimes fails for me. 
• Collaborator views the main instead of the DEV and you have to explain about the dev branch. 
• I lose track of the merges and worry the wrong work has ended up in the wrong spot on big documents. 

For branching now I try to only use it for those times I want to compare a few different design scenarios off a version, not put to much work on a branch and merge before too much has been added on the main branch. I am also trying to prune branches back where possible and reasonably soon after creation to keep thing cleaner. 

john_mcclary

@brucebartlett I agree, the DEV REL branching adds work IMO

I end up going back into the merged REL and find a bunch of crap that I got rid of in DEV.
I know it is a system that only adds the two together. But I would like a replace option as well as merge.
What I expect is REL is the latest revision of DEV, rather than merging the branch then going back into REL and purging all of the features/tabs that you removed during development.

Only time I find myself using branches is for support tickets or complete re-designs

MBartlett21

john_mcclary said:

Only time I find myself using branches is for support tickets or complete re-designs

Great use

owen_sparks

Hi John.

john_mcclary said:

I know it is a system that only adds the two together. But I would like a replace option as well as merge.

Me too, I want a right click "Make this version Main" option to kill the existing main and replace it with the current state of a brance.

In the example below I've branched early and plowed on with the Main, creating versions as I go.  I've then come to the conclusion that it was a bad idea and want to pick up from one of the other earlier ideas.  I don't want to merge, I want to kill and replace.

Like so:-

Does that make sense?  Am I missing the point of the existing functionality?

Cheers,

Owen S.

mlaflecheCAD

I like this discussion.  There is a very timely webinar next week in this topic that Neil is running.   https://www.onshape.com/managing-design-teams-collaboratively-with-github-style-branching-merging-070318

owen_sparks

@mlaflecheCAD

Groovy, good to know.  Thanks for the heads up.

Owen S.

john_mcclary

Signed up

EricGauthier

Hi all,

@mlaflecheCAD , I already read this article more than once.
@brucebartlett , I agree with all your reasons, especially #1, 2, 5 and 6.
@john_mcclary , I agree branching adds work.

I first thought branching was going to be a good thing to explore many layouts in parallel while starting the design of a new robotic cell (which is what I do everyday). The problem is I can't modify a sub-assembly in a branch and merge only this modified sub-assembly to another branch if both branches are very different. I have to create a branch just to modify this sub-assembly so it means I have to plan exactly in advance where I want the modification to take place.

See image where both layouts are separate branches and where I would like to test a different rack design. I have to decide if I want to test it in only one layout or in both layouts before I even make a single change to the rack itself. This example is simple but when I'm making many (more than 2) layouts for a customer, it turns very complicated to follow branches...



Am I missing something?

kevin_o_toole_1

@owen_sparks
In Onshape, you can "kill and replace" a branch in exactly those two steps

First, open (double click) the moment before the branch point, and click the "Restore to Main" text at the top. This reverts all changes to main that have occurred since the branch point, restoring Main to that previous state without the unwanted changes.


Second, go back to main, right-click B1, and select "Merge into current workspace".

After these two steps, your main branch should be in exactly the same state as B1.

john_mcclary

@kevin_o_toole_1
Thanks for making the explanation simple. I will need to experiment with that now

owen_sparks

kevin_o_toole_1 said:

@owen_sparks
In Onshape, you can "kill and replace" a branch in exactly those two steps

First, open (double click) the moment before the branch point, and click the "Restore to Main" text at the top. This reverts all changes to main that have occurred since the branch point, restoring Main to that previous state without the unwanted changes.


Second, go back to main, right-click B1, and select "Merge into current workspace".

After these two steps, your main branch should be in exactly the same state as B1.

Brilliant, thanks for the explanation.

That "Restore to main" was the bit I'd not appreciated.  It's great to be introduced to stuff you might have missed, no need to even wait for an update.

Thank you :-)

Owen S.

billy2

Branching seems to be working for me:
When working with others and branching, it becomes difficult to know which branch has the 'good stuff'. Naming the branch is critical to finding it later. Many branches just end and trying to remember the branches with the good stuff becomes problematic. We're deleting the workspaces at the end of dead branches to help designate which branches went no where. 

I know github's branches always merge back to main, I'm still wondering why my OS branches don't.

All in all, I'm expecting my branch/merge diagram to look pristine like in the demo,  but in reality it's typically a mess. Maybe over time, it'll look better.





Merging works when:
-dealing with a limited number of changes (20 features or changes) in a branch
-being extremely careful what I do in the branch to be merged
-not changing colors or other little details
-stay focused on the one change

Merging works when I know why I created the branch and I know  what it's merging with. Typically it's a low number of changes that do something specific. If I begin to change colors or clean up stuff that's not part of my original plan, it blows up.

Taking a weeks worth of work and merging, doesn't work for me.

brucebartlett

This is a great discussion and making me look again at how I use branches. Looking back the Dev branch method it is definitely a good way to work but you have to plan and have the discipline to makes sure work is always done on the DEV, as it is so easy to have stuff happen back on the main. And always keep the other exploratory branches short and deal with them quickly before things get out of hand.

@kevin_o_toole_1 thanks for the example showing how to kill the main before merging this is a good option however it would be great if you could actually turn the main node of for a dev branch workflow. 

Here are some examples of my dev branches, I haven't used Release management on any of these yet but that's another great use too. 






There is also the power to do lots other things with branches too but takes alot of planning to make it successful, otherwise, you end up with a mess

billy2

Trying to get things back to main. Merge worked, didn't think it would. I was expecting some kind of graphical indicator showing the merge like @owen_sparks shows above. It is listed in the changes.



I still don't like the above branch&merge diagram because it's hard to understand that I've given up on these other branches.

Below I prune the tree:


Now it's obvious which workspace is valid. Also notice that if a workspace had no versions, they're totally gone. I like this. If I want to reactivate a dead branch I can create a new branch from one of the dead versions and reactivate the branch.

I'm learning to name everything and there are no versions without a name. I don't use versions as a save, but as a marker before and after I do something. I try to describe what I'm going to do and what I've done and mark when the design is valid/stable. Clicking on a version will bring you to state that has no errors and was something completed.

I don't use the 'B' designators for branches, but naming them is extremely important. Why are you branching? This is what I ask myself. 3 weeks from now I won't remember why I branched.

It's seems to be working for me, not sure it's right for you, but I thought I'd share.

brucebartlett

billy2 said:

I'm learning to name everything and there are no version without a name. I don't use versions as a save, but as a marker before and after I do something. I try to describe what I'm going to do and what I've done and mark when the design is valid/stable. Clicking on a version will bring you to state that has no errors and was something completed.

I don't use the 'B' designators for branches, but naming them is extremely important. Why are you branching? This is what I ask myself. 3 weeks from now I won't remember why I branched.

It's seems to be working for me, not sure it's right for you, but I thought I'd share.

Yes, great point Bill, you can see from my example above with heaps of branches & versions, I have totally lost what has been done and I am reluctant to delete/prune because I fear losing work. If I had planned better and used more names and descriptions it would make life a lot easier to sort through the work and prune un-needed braches. 

billy2

@brucebartlett please post more, it helps to talk to someone about this stuff. I've never put much effort into merging back to main, but after reading this post, I got to it, and made it work. Keeping main alive is important.

I have a few dozen live documents representing several common projects that I'm currently working on. Each document has 3 or 4 branches and finding the correct workspace is becoming an issue for me. Couple this with not being able to preview inside documents and  their workspaces when choosing which document to open, I was forced to remember where things were. For me, remembering where things are isn't a good workflow. I've never liked that a branch becomes the active workspace forcing me to remember which workspace I should be in. Putting things back in main is a good workflow and I'll put more effort into this.

Your dev & rel branches, are these released and develop?  Is release is your main branch? I'm still trying to wrap my head around your work flow. You could have rel & dev1 & dev2 & dev3 for 3 possible solutions that'll end up is rel?

I have had 2 active branches and I've wanted new changes to end up in both branches. I did use a 3rd branch for the changes and successfully merged them into each active branch. I deleted the 3rd branch after the merge and it did work. I think I was successful because my 3rd branch was a small amount of changes. This seems like a valid workflow. 


Currently my approach to building projects in OS is to keep things simple. I have small projects that are scaling up nicely with more power than I've ever had before, but I'm restraining myself trying everything in OS, but instead, I'm taking a conservative approach to figure out what works and what doesn't.


Not everything is rosy in my camp. The other day I moved the wrong document into another document. When moving it back, I forgot to move it into the correct workspace. Everything I did was making things worse. Messed everything up and instead of correcting it, I just restored to a previous version which I don't like to do. This isn't OS fault, it's just learning a new system and knowing what to watch for.


 

billy2

@EricGauthier thinking about your situation, I'm not sure I'd branch one document to achieve your results. I think you're trying to do too much in one document and getting branching to work with 2 assemblies and a frame partstudio. The issue is branching & merging works at the document level and I think you should only be branching the frame.

So....

Move the frame into it's own document.

I think I'd try and keep an assembly in one document and then have a document for your frame. In the frame document I'd branch it to the nines with all the ideas you have for the frame.

Warning, when using 2 documents, OS will invoke versioning/updating and at 1st you'll think it's a pain. After a while you'll start to like it and begin to accept it. I didn't want to use it at 1st, but someone I work with forced it on me and now it's part of my standard work flow. I'm using multiple documents for very simple projects and have to restrain myself from over using it.

To move your frame to it's own document, just RMB the tab and move it to it's own document.

You'll have to update your assembly with versions of the branched frame. I think this is good because when in front of your customer, you just dance through your assembly versions showing the differing frames. You won't have 2 assemblies, rather 2 versions of the assembly. I'd put some thought into naming the versions. I've posted enough about this already.

Once you're done, move the frame back into to your single document. FYI, the branch/merge tree goes away when you move it back so pick the right frame when moving back. This might be what you want. If you want to keep the history, leave your 2 documents intact.

I'm not sure how many people are putting documents inside documents and possibly this should be another forum thread. I think it might be the key to get your situation to work and might explode into a way to control all these variations you're looking for.

Please let me know if my crazy idea works.


 

EricGauthier

@billy2 I'm not sure I want to separate my assemblies and parts into many documents when designing at early stages of a project. Like you said, I can create versions but I'll always be working with changing versions and I'm almost convinced I will loose time (even when I will be used to) rather than gain some.

As discussed with Onshape support team, probably assembly configurations will resolve my problem. I'm waiting for it!

billy2

@EricGauthier assembly configurations sounds like a great solution,

shouldNotBePosting

@brucebartlett I'm not going to let this thread die. Learned GIT this weekend and put my software project in it. Surprisingly, I think we can benefit from how those guys do it.

Basics for GIT Branch & Merge paradigm:

• don't work in the main branch
• merge back often
• name your branches

In your example with many unknown workspaces:

• I'd make the workspace active
• then version it, the version gets assigned to the active workspace, allowing you to delete work space without losing changes
• I'd name this new version the workspace name, because the workspace name is gone after deleting
• merge back to main, merge a version vs a workspace, versions seem to merge better
• delete the workspace, since it's just been versioned, you won't loose anything
• after merging version to main, version main and add a description that it's been merged, there's nothing mentioning merging unless you open changes and search for, it'd be nice if there was a graphics showing merging

Anyway I've been cleaning this stuff up:




GIT seems to have it's own problems and issues similar to our issues but they seem to have some etiquette to their process that allows it to work. I'm not an expert at either but willing to share experiences. With the right process, I think this will become a powerful tool.

brucebartlett

@billy2 , keep up the good work, there are some definite advantages to mastering these workflows. I've changed my workflow again, I was branching and working on a branch and merging back to main regularly to ensure the main had up to date work but I was ending up with very branches with lots of versions. I am now following a workflow of versioning on the main, branching and working until a milestone (maybe with a few branch versions then merging back to main, versioning and starting a new branch from the new version on the main. This way it makes it very easy to prune old branches and branch versions back when not required anymore. 

shouldNotBePosting

@brucebartlett I'm also working in main more than in the past and won't let branches rule a project.

Yesterday I started a new document vs. branching an existing design. I think the tendency is to gather everything into one document using branches, but I'm not sure this is the best practice. Not certain what the rule should be for branching vs adding more documents.