Hi, everybody. Welcome to what I hope is gonna be an interesting talk. We're gonna talk all about branching, branching in content management rather than branching for developers. We'll see why it's specific, and we'll also do a demo or a tutorial, you might wanna call it, in how branching actually works inside Paligo. If you haven't done branching before, I hope you've had a good night's sleep. I hope you've had a good strong coffee. We make branching as easy as possible, but we also might have to think a little bit. But we're gonna do it in a stage by stage process. But whether you come from a environment, say example in Word, where you haven't done branching before or you come from an advanced system where you're familiar with branching, we're gonna set the pages, we're gonna set the levels so we're all, by the end of this small and brief presentation, we'll all be on the same page as we jump into Paligo and see how it's done in Paligo. This slide really is just an introduction to Paligo as a whole. You know, like with some systems, like, say, HubSpot, you could choose one part of a product, let's say, sales, but not use the marketing or vice versa. Well, Paligo is much more inclusive. Many things work together a little bit like a metaphor of an arch. If you think about it, if you look at the top of an arch, it's kind of impossible to build that top brick so it won't fall down. How do you do it by first building everything else around it and using all the scaffolding so things don't fall down? It's all one big arch together. So in Paligo, we have our authoring. We have all our different types of reuse. We have the versioning and branching, which we're gonna talk about in detail today. We've got the whole collaboration process where the SMEs can contribute and edit content and put their comments in. The translation process, which is critical when you're selling your product into, different countries, and the publishing sites. They all work together. So the branching is very much an integral part of the system. As we'll see, maybe it wasn't twenty years ago, but it most definitely is now. So what's the old story? When I started writing, and to be honest, that was a long time ago in 1993, life did move a lot slower. You basically had a release maybe once every six months, and you did it in a simple draft process. And then the next release was six months later. There was no need for parallel releases, no incremental updates. Life was much, much simpler. And then whether we like it or not, agile came along and it basically messed everything up for keeping our docs nice and simple to manage. It's in our step by step process to product improvement. So our docs have no choice but to parallel that way of working. And we also need to have these incremental updates to our documents, not once every six months. So it's that extra level of complication. So the question is, how can we go and maintain multiple separate releases of our documents, but still reuse content from previous releases? So if you were to take Word as anan example, all you'd be able to do in Word is save as into another document. Then there's no reusable content between those two documents. So if you want to update a section in both, you need to manually go and make the change in both of those documents. Obviously, potential cause for mistake and there's no reuse. So how can we do that? So the way to do it is via branching. So branching is the method for maintaining multiple versions of documents to closely mirror the concurrent versions of the product release. That's my words, by the way. It's my definition. And I specifically wrote the word closely before mirror intentionally amd I'll explain to you why. So you're going to have multiple releases of the documents, whatever it is, once every two weeks, once every month, or every three months, however your your your company releases their their versions. And you're going to have to mirror that. So the release date will have to be similar. You'll have to have that you'll have to have your different versions ready at particular dates. Now we're not gonna do it probably the same as the the R&D department, the developers. We're gonna probably do it in a different way because we're managing documents and they're managing code. Another slide talks about that in a second. We're gonna closely mirror it at least. We have to be ready around the same time. So they've got their different versions. So do we. That's what branching will allow us to do is to manage that process. And in Paligo-ish, branching is also part of the reuse paradigm where we reuse content between the different versions. So if you think about it, version 1.2 contains ten percent difference, whether it's additions or deletions or edits, to version 1. So we essentially wanna keep reusing the same content from version 1, but just work on the delta for version 1.2. So it's all branching and reuse very closely linked together. I love this one. It's my metaphor. I hope you like it. I'll stay out of your kitchen if you stay out of mine. What do I mean by that? Let's say we say to a developer, dear developer, I want you to manage all your code inside Paligo, a component content management system. And I also want you to manage all your versions inside Paligo. I assume the developer would say to me, are you out of your mind? How could I possibly do something like that? We're code and you're content. So I ask you, why do sometimes content people end up managing all their content and versions in a system created for developers. Writers should keep out of dev versioning like devs should keep out of content versioning. Our world is different to code. Maybe there's some similarities, but they're different. So one should be using a versioning and branching methodology built specifically for content. So we'll talk about topics. We'll talk about informal topics, talk about notes, we'll talk about publications, not one that was built for a system for managing code. So I'll stay out of your kitchen if you stay out of mine. So a typical release use case, again, when I started writing too many years ago, you'd start at the beginning on the left, get a first draft, second, third, maybe, and then off to release if you created version one, and then you do your 'save as' and another line not connected for your version twos. But now life is changing. So one case, which is actually quite similar to how developers work, because developers, they tend to create a separate branch which works in parallel to the original branch and then merge back in, which is this dot here, into the original. Say, Paligo, we actually work that way as well because we're a cloud-based product. We don't have multiple versions out by our customers. So we will create a parallel branched version, which is not connected to the live version. We'll work on our changes, add on new exciting features, and then at some point in time, we'll merge them back into the source and release. So what it says version 1.0, we probably call version 1.2. That's actually quite similar to how developers work. But in content, you often see this case as well where we don't merge back. We might make a branched version of our publication, of our whole documentation or part of it. But say it's a piece of hardware. So version 2.0 is released in on on top of version 1.2,. It doesn't get merged back. Maybe also version three. We call this sequential branching, where one branch is built upon the other, still reuse from and there might be reuse from version 1, still being used in 1.2, 2.0, and 3.0. Those would be its unique content. So there are two different release use cases that we've seen, either the kind of more cloudy one where we always go back into the original, or it could be the multiple versions, one based on the other. I hope everybody's with me awake and following. There isn't too much far further to go in the presentation. So now we also have a case regarding translations where we will have a normal case right as we have. But let's see what happens. What happens, and I've had pains with this in my many years of doing consultancy, where you've got an English version, you send it over for translation, and then suddenly someone in the middle, before you get it back, needs to modify and update the English version. And they go and do such a thing, criminal I know, but we've all probably been there at some point before. So when the translation comes back, we have a misalignment because the English version is not the same as the translated version. And I can tell you that leaves you with sleepless nights, you know, probably for the whole week. We need to avoid that happening. So how would we do that? So first of all, we'd merge our content. We so we would branch our content like this, like we saw in the previous slide. So we'll have our version sent out and merge it back later, but we must take into account the translation side. This first red dot, the CMS, by the way, is a translation memory system. That's the systems that translating organizations, localization companies, they use for translating your content. So the order time-wise would be, I've got my English version, it's ready for translation, send it to the translators. I need to update, so I'll create a branch of this update, but look where I'm actually sending the translation back. Make sure the translation comes back into the source before you go and merge with the changes to the English version. And this is a common case of using branching in Paligo for managing translators to make sure you don't have misalignment and you don't have sleepless nights to ensure this goes correctly. So this slide, hopefully, if the points in this slide all make sense to you, I've done my job and I explained the basics of branching to you. Let's see if it all makes sense to us. So we work on version 1.0. We complete it. Nice and easy. Then we create a branch for version 2 to add new features or changes. So we'll, first of all, we're using the same content from version 1.0 apart from those delta. So we're adding, editing, or deleting content. And we also might do something else. We could go back to working version 1.0 to fix bugs if you remember the the slide with the line above. You could you could actually be making changes to version 1.0 and version 2.0 at the same time. Some of you might say, okay. How do I merge those together? So later on, when I show you how it works in Paligo, we show all the merging sides, and you decide exactly what goes in. There's no such thing as a clash in Paligo because you decide what's merged before you actually get to a clash, a point in time. And then either you can merge changes from version 2 back to version 1. So we'll always have that same release source and call it version 2 like I explained to you before in the Paligo world, the cloud version, one single version. So we'll always merge back. We don't need those multiple versions. Or we can keep both releases live because we need to support both releases or even multiple releases in the market. So as I said to you before I started this slide, if you all understand what I just wrote, we're all in a very, very good place together and ready to move on. So in Paligo, we can branch all different types of components. I'll list them here, explain them briefly. But we'll go back into Paligo, and we will see the differences between them and use cases when we use each one. So number one is the actual publication. We can branch a whole publication. The second level is we can branch the actual topics, the source topics. It says, you're getting started in this example. The third level, we can branch what we call forks. For those who aren't familiar with the term of fork, the actual topic you see in is in the topics folder. You can see getting started. We're using the getting started topic inside a publication. The use of that topic inside the publication is called a fork, because it's not the actual topic, it's the reuse of it. So we can branch a topic or we could branch the fork topic in a publication. We're gonna see what the difference is technically wise, and we'll just discuss why would we want to use one or the other. Number four, any other components, for example, informal topic or in this case, an admonition. It's a warning. We're not gonna do that inside Paligo itself, but I think you will understand. So now it's time to jump into our product, and we'll do an actual demo for you. So now, everybody, here we are inside Paligo, and we're gonna do branching inside Paligo itself. I would suggest if any of you here are completely new to Paligo, it might be worth you going and watching a regular demo or speaking to someone at Paligo to help you and originally get up to speed a little bit, understand the basics. But I will also do my best as I go along to try to explain, but I just say it might be worth going back. For those of you who've been using the product or new to the product, this hopefully will be really useful for you and helpful to you. So you can then understand once I've shown you the basics of branching, maybe you'll start thinking, okay. How do I implement it in my company? Or how can maybe change how I'm doing how I'm doing it in my company? And I can also suggest to you, if you wanna talk to me or someone else at Paligo about your information architecture, about your strategy, maybe I'm gonna introduce ideas that you think, oh, that's a good idea, but how do I do this? Or can you look at my current integration? So be in contact with us, and maybe we can arrange a meeting and talk about things because it's all about one thing here, trying to ensure that you have the best possible infrastructure, the best possible environment for you to prosper with your documentation inside your company. That's where all this comes from. So I have now let's say, a typical case. I've got a publication with a whole bunch of topics in, and I've got some topics down here. Normal Paligo situation. So if we saw before, the first thing that I'm going to branch is my publication. So let's do that together and see. And that's often the case what we actually do. We're gonna look together and see what happens when we do things. Then we'll explain it. So branching and new branch. The first thing you should get used to is adding a label. Without a label, it becomes very unclear how everything's connected together. So this is really gonna help. This alter branching, I will come back later and discuss that. We're just gonna create a branch of our publication by clicking create. Depending on the size of the publication, so how and how long it depends how long it's gonna take. But here we see we have now a publication where the source publication is here, as you can see by the icon, and here is the branch publication. So you need to add the label just to make it clear what's going on. You can also search for labels as well later on. I would also suggest for good cleanliness and hygiene that we also label anything we've created a branch from. So we'll go to the three dots, branching and edit label, and we'll call that version 1.2. You can see I've done this before. So we now have essentially two identical publications. If we're going to be specific in terms of the language of forks that we mentioned before, so we have, for example, create a team here in the repository. This is the actual topic. This here is the reuse of this topic in this publication called a fork. That's fork number one of this topic. And the same fork, exactly the same topic is used here. And if you guys know, if I click on create a team here or here or here, they will all open the same editing or the same topic to edit, which we're not going to do just now. Just a chance for me to explain that to you. So the next level maybe we can do is just to change the structure of the publication. So let's make sure on version 2 when we are. Let's do a couple of things. Like, for example, can get rid of setting up and I'm gonna add something else from my system, for example, payroll. Put that there instead and save. So I now now have two different two publications that are different. There's the version 1.0 and there's version 2.0  So they're slightly different. It could be if you're very lucky without a lot of work to do. Maybe you finished. Maybe there's no more work to do. You finished. You can then go like any other publication. A branch publication is like any publication you go to publish. You can your settings, you guys are familiar with this, and, you know, publish out. You can even copy settings, by the way, from one to another. And just please not look in our documentation if you want help with that. And it could be you finish it and you go home. That could be the case. But it also might not be the case that you probably need to do a lot more work. So let's go to the second stage. So we've branched to publication. Now we're going to branch an individual topic. So I'm going to take my topic here, managing teams, and I'm going to create a branch out of it. I go branching, a new branch. And if you see that Paligo has now created a new branch, there's the source, and there's our branch. Click on these three dots, branching and edit label because we wanna keep ourselves nice and tidy and clean and hygienic, as I said before. I would rename I would give this a label as well, but I'm gonna delete it soon. And sometimes you might need to refresh the publication to see the change. And if we look here, we will see that both publications are using the same topic managing teams, not the branch version. So what if I wanted to use this branch version two inside this publication, what would I do? I often ask this in training sessions. Hopefully, some of you have already thought of the answer. So what I would do, I go to edit and open the structure. So if I was to bring managing teams, I would actually remove it from here, bring the new one in and put it in the right place. So in other words, I would manually move the topics that I need, take out the previous version, bring in the branch version, put in the publication, and save. So if I branch on the topic level, I need to manually play or, modify the structure of the publications accordingly. That's what happens when you manage when you branch a topic. Let's discard that. Keep it as it was. And I'm actually gonna delete this because I wanna do something different in a second. And I also wanna teach you guys how to delete a branch. There isn't a branching delete. You just do regular delete. And if I do that, Paligo has removed, you see, the branch from here. And if I open our two topics, Paligo also shows me that there's no branch icon here because the branch has been deleted. So Paligo goes backwards and basically fixes everything that's been affected from the branch. So we've branched publications and we've branched topics. Next on the list is to branch our forks. And as I explained to you before, a fork is a reuse of a topic in, in our case now, a publication. What I'm gonna do is I'm gonna branch the fork. We'll look what happens, to learn what happens when we branch forks. I'm not gonna explain to you in advance. So I want to actually create a different version of managing teams in version 2 than I do in version 1, and I'm doing it on the fork level, the reuse of that topic in this publication. So I'm going to the three dots, branching and new branch. Watch the magic that happens. So you can see here that we have the two topics branched. So let's be hygienic: branching, edit label version And branching edit label version 2. Now we're behaving nicely and tidily. Let's go into the publications and have a look. So our first publication says it's using, as we'd expect, the original topic. If I go into version 2, watch what happened. Paligo is automatically using the the branch topic instead. Because I branched the fork, Paligo understood that the fork needs to be in that branch publication. You're right. We could manually do what we did before with the topics like I first showed you, but I think you now understand the difference between branching a a topic against branching a fork. Really useful and it saves you a lot of time. So your question might now be, okay, so why? When would I use branching a topic and when would I branch a fork? And everything with branching, everything else, it's subjective, different use cases. But this could be a a good answer. If you're like us, one single cloud-based product, I would branch the fork like I've just shown you. Because it's really one to one. That branch is only gonna ever be used in this basically one one publication. But let's say I've got one topic that's used in five different products, five different publications. So I can't go and branch every publication fork like this topic fork. I'd end up with five different topics. You might then want to branch the topic separately and then move it, as I showed you originally, into those five publications accordingly. But, again, there's lots of different use cases. What I would suggest you do with this and all the parts of branching is as I'm doing it, maybe even the stuff I've done previously, try it out for yourself. Maybe stop the video now. Go back. Branch a publication. Branch a topic. Branch a fork. See if you end up with the same results that I do. I wanna show you something else. I wanna show you how you can see how things are connected. If I go to this topic, for example, and I go edit structure edit open structure for this topic, you might be familiar with this page. You have metadata on every component, and you can actually see here, it's telling me it's a branch of version one. And if I click on it, you see at the bottom, it says locate. It would go to the appropriate folder. So you could end up the whatever your, you know, infrastructure is, you could end up having a topic to a topic and it's in its branch topic, maybe a different folder, a different version for your folder, a different folder for your version, and they'll be able to quickly find where they're located. So you're never lost. The database behind the scenes in Paligo always will give you a perspective of where you are and how things are connected. That's a piece of useful information. So what's the next thing we could do? We've done our, created our public we've got branch publication. We've got branch topics. The next thing is we want to change a topic. Alright. We've got this version 2 managing teams. I've made a branch of it, so we want to edit it. So let's go and edit it. And so here's the topic. Note, by the way, at the top, you can actually browse between the original branch and the branch version. And without connecting to branching, if you ever wanna click on one of these, this actually takes you to the folder where the the hierarchy of folders is a quick way to get to the actual folder. So let's make let's make some changes. You can... let's change that to arrange your your teams. We'll just put the word in a way. We'll remove that word, and let's add a a new sentence, branching rules. So we've now got, you would agree, differences between the two topics. So I like let's go and have a look at the original topic. There it is. So we can see the differences between our two topics. So it could be we've finished. We've done our branching. We've restructured our publication. We've branched our topics. And if it was the case like I showed you previously, where you have the version 2 and version 3 inside the presentation slides, inside the presentation, I'll I'll show you here. This slide here. When we never merge them back together, we've actually finished our work. There's nothing else to do. We've completed our work. Okay? So that could be here. You go to publish, you released, you can go home, everybody's happy, the customers can use your product or your service, and we're all good. So in many situations, we actually want to merge our content back. We want to go back to the original, whether it's the translation scenario we spoke about or whether it's merging into an, an original version to keep that same line. Whatever it is, we might need to merge our content, and we can merge at different levels inside Paligo . We can merge at the topic level in our example, and we can merge at the publication level. Again, you can merge admonitions and can you can merge informal topics. We're just not doing that just now. So we've got our two topics here. So we'll go to branch and merge branch. Now you could have multiple branches. In our case, just one, so we select the original branch. And Paligo is gonna show me exactly what's changed between our versions. On the left hand side, you can see the original topic. On the right hand side, we can see the new topic or the branch topic version 2. What we're going to do is decide what changes from version 2 head back into version 1. So you can see here that I changed manage to 'arrange your'. You see if I click a button, it'll it'll change them back from range to manage. I added branching rules. Do I wanna keep it or do I want to lose it? Do I wanna leave simple in or take it out? Okay. So maybe I'll leave it in, and I want I like 'arrange yours' better than manage. This is why you have no clashes. You decide exactly what goes in even if there's a period or comma difference, you'll see and be able to decide. So if I were to leave it like this, the change is this, and I can also go to to preview to see what it looks like. So I'm not confused. So whatever is in this screen on 2, if I press merge, we'll push it back into version one. To be clear, version 2 doesn't doesn't change. Version 2 exactly as it is before I went into this window. What we're doing is what changes from version 2 do I want to bring into version 1? That's what this screen is showing. I'm not gonna press merge, but I possibly could. And if I wanted to delete the branch when I'm completed, I could press that button as well. So that explains how to merge topics. We also might want to merge our publications. So in the same way, I think you're all getting the idea. I'm going to branch and go to merge branch, and I'll choose my branch and click next. I think this is really, really helpful and useful. You can now see the differences between our publication branches. Do you remember the removed setting up from the original publication from version 1, and I added payroll to version 2? I can also decide here is I wanted in or not it wanted in for each of these different topics. Very simple to decide what goes into my new, again, version 1. We're deciding what wins the game to be in version 1.0. And Paligo also knows that I changed, I have a branch topic, managing teams. The plus will accept all the changes from 2 to bring into 1. The this will reject all changes, meaning version 1 will not change at all. And this screen, you should all recognize, goes back to the same screen I had before. I can decide what goes in. If I press merge, Paligo does not save, doesn't actually activate those changes yet. It will only be activated when I would press merge. So you can play around with that. Don't be scared of those changes being implemented before you actually press merge in the publication. And if I press merge and you can please try this yourselves later, you'll be able to merge that content. And as I said before, please play with this yourselves. Even watch this again, if you don't mind listening to me twice and just mirror what I'm doing in your system or create your own example content and play with it. The thing with branching and also with reuse in Paligo is the more you do it and play with it, the more you become familiar with it. None of this is hard. It's what I call, you know, muscle memory or brain memory. It's just getting used to the functionality, and then you can fly with it. But that's the basics of of branching. I want to explain another couple of things to you. Okay? But that's the these are the basics of branching. I hope everybody's again, we're all on on the same page. If we remember the screen that we had before, when I went to a publication and I went to branching, new branch, there were a couple of options at the bottom here. I just want to explain what they are and maybe a use case why you'd want to do that. We'll specifically concentrate on this topics one. If you remember, when we branched our publication, Paligo only branched the publication itself, not the topics. We had to manually go in and say, please branch this topic for me, Paligo. If I press this tick box here, this check box, every single topic would also be branched. So I'd have basically double the topics in my system than before or double the topics for this publication that I did before I press this option. Why would you do this? I actually had a customer, give me a good use case for this a couple of weeks ago. They want all their contributors who can go in and edit content to potentially change any content in the whole in in in the publication whenever as as they want to join the process. But it mustn't affect the original content, because that's still being updated by the tech writers, any bug fixes, or anything else that needs to be done. So in their case, they say it's worth it worth it to have many more topics in the system because we want our contributors to change anything. And then later on, the writers are able to decide what goes in, what doesn't go in. They'll merge as we just saw a second ago and decide what goes in. So that's why you might want to. By default, I would not do it because it creates so many extra topics. But if you got if you have a use case that warrants it, please do it. And the same thing with publications, you can insert publications inside other publications and also branch those publications. I'm gonna go to our managing teams, and I'm gonna create a new version of it. So I'm gonna go to branching, a new branch. Now I wanna teach you something else that's also really important. We call it sequential branching. It's if you have multiple levels of branching, how do we manage that? And I'm gonna show you. So let's go to our settings. I'll actually open it in a new tab so we can keep our original window as it was. And I'm gonna go to to system settings. We've got this thing called enabling advanced branching. I'm gonna show you, and we'll learn as we do it. So I'm gonna go to version 2, and I'm gonna go to branching and new branch and watch what happens. Paligo has actually just created another level underneath version 1.0. That'll be even clearer when we do our next thing, but let's label this branching edit label and call it version 2.1. So we can see now that basically version 1 is basically connected to 1 and 2. How can we see? Again, let's go to the metadata really quickly, and you'll see it's got two branches, one and two. Or 2.0 and 2.1 as we're calling them. But now let me delete this one. Do you wanna show something else afterwards? That's gone. Good. Let's go back into our settings and turn on enable advanced branching, and let's see the difference when I branch again now on version 2. Branching, new branch. So it's the third branch we've created. I know it's the second one we see on the screen. It's the first third branch being created in our case here and it's connected to number 1. And as you can see, version 2 is a branch of this one, but it's also a resource branch for this third one. And if I actually set.. look at the metadata for version 2, it tells me I'm a branch of version 1, and it's got its own branch, which we haven't labeled, have we? So we gotta label it. So we go to branch, the label. We'll call it version 3. So we've seen the non sequential where if you do it on the second level, it just creates another one on that same level. You will get to a third level. Or turn on the sequential or hierarchical branching, and we have this third level. So we we keep doing this forever. We could have, like, fifty or a hundred levels. That's not practical. Obviously, at some point, we wanna cut the levels. So let's take this scenario. We always have two versions of our documentation live in the market. And as soon as a third one comes out, we stop for sure working on the first one. So what I want to do, I basically want to kick out the connection between 2 and 1. I wanna make 2 the top level. I don't want it to be related anymore to one, and I want version 3 rather being the third level. I wanna jump it up one to only be the second level. So how do I do that? Let's have a look. So I'll go to the version 2. I'll go to branching. And which of these options do you think is the one that makes sense at the screen on the screen? Convert to main branch. I wanna disconnect 2 from 1. I want two to be in the main branch. Let's just be double sure they're on the same level. Yes. We are. One two. Why don't we get the top level? Branching, convert to main branch, do confer. Watch what's happened. You can now see there's no connection anymore between version 2 and version 1. And I actually have to refresh this this folder and you'll see that now there's only one level. It's not two levels version 3 and it's connected to version So now you are all officially certified as Paligo branching experts. But I want you to remember one lesson that we always talk about training is the KISS principle. Keep it simple. Well, none of us are, but keep it simple stupid. Meaning, when you're implementing your branching strategy, also try not to make it too complicated. Make it so everybody can follow. And if you want, as I said before, you can always reach out to us at Paligo, and we'll always try to give you some advice, consultancy, and comment if you need some help. Because I understand branching itself in Paligo is not a difficult process. You've seen all the different options that we have. It's just pressing buttons. The human side, you might need a little bit of help or you might need to think it through carefully. You're more than welcome to reach out to us, and we'll be happy to help you. Happy branching, everybody.