Version control is a fact of life for any software project. Whether you're writing code with a bunch of other people, or it's just you doing your own thing in your spare time, you need to find a way to manage the different versions of your software, the features you develop, and what you're releasing to the public.
This post discusses how Codebots manages version control, and explains how you can use the Codebots version control system to see what the bots have written, and write your own code to augment and improve it.
When you have set up your project in the Codebots Platform and designed your initial structure using the Diagram Editor, the bot will go ahead and write the first lot of code for you. It stores this code in a repository on GitLab.
When we were creating Codebots, it was really important to us that the code the bots created was developer-readable. That means that you can go and take a look at the code the bot has written for you whenever you like.
You can do more than just look, though! When our codebots write code, they add in protected regions, which is where you can write your own code, and the bot knows not to mess with it. This is how you add custom functionality to your project.
Version control using git can be confusing, but it works on creating a series of branches, which are basically copies of the code. This lets us completely screw up what we're working on, without ruining everything that has already been done. If there's a problem with something, we can just delete the branch we're working on, or undo our changes, and go back to a stage where we know the code worked without any problems.
First of all, we have a Master branch, which is the code that we will eventually release. From that, we create a Development branch, which is where we're going to do the actual work. If you were just one developer working alone, you could probably do everything you needed to do in the Development branch. Feature branches are created as a copy of the Development branch. Once a feature is complete, it is merged back to Development. And then when you are ready to test and release, merge the Development branch back into Master and release it from there.
If you have more people (or bots!) working on your code, it's a good idea to use branches to manage the work on individual features. It looks a little bit like this: