Imagine you have written a complicated program, it took ages, but you have finally got it all working, and you are feeling very pleased with yourself.
Then you decide to make a few little tweaks in a couple of areas, to make it even better.
You retest it, and find it isn't quite working properly any more. Never mind, you can just undo the changes and get it working again.
So you undo all the changes, or at least all the ones you can remember. You think the code is the same as it was before, but you can't be sure exactly what it was before you changed it.
Now the program doesn't work at all, it just crashes. If only you had made a copy of your files when everything worked, before you started messing about with it!
The way to avoid this situation is to make a copy of your working code before you change it. That way, if anything goes wrong, you can always go back to the working copy and try again.
This is called change control. Here is a simple way of doing it:
Now if you make mistakes in your work folder, all is not lost. You can simply copy the most recent archive files into your archive folder.
When your program is complete, be sure to save the files into an archive folder called something like V1.0. Then if you want to carry on adding new features, you can create more dated archives, and eventually new versions of your software.
This simple scheme is fine for one person working on a small project. When you are working on larger projects, and especially if there is more than one person working on the software, you might need a proper change control system such as Git.
We will use Git as an example of a modern change control system, but this section isn't intended to be a Git user guide! The good thing about Git is that there are various free online servers that you can use to check in your code, and develop shared projects with your friends. The most famous is probably github, but another one is bitbucket, and there are others.
With Git, all of your files are stored in a repository (or repo). Quite often, the main repo will be on a different computer (a Git server). For example you can use Github as your server.
When you want to work on your software, you copy it from the server to your own PC - this is called checking out the software.
Each time you make a significant change to the software (for example adding a new feature or fixing a bug), you copy the code back to the server - this is called checking in the changes.
The server records which files you changed, what changes you made, and the date and time you checked in the changes. You can also add a message to say what the purpose of the change was (for example, which bug it fixed).
The change control system allows you to look back at all the changes that have ever been made to the software. You can pick on a particular file and find out what changes you made last week. You can look at a particular change and find out which other files were changed at the same time.
When you decide that your software is ready, you can label the current files. For example, you can label them as "V1.0". The system remembers the exact version of every file that was used to create that version of software. If you make more changes later on, for example to add features for the next version of software, you can still get V1.0 back any time you like by checking out the files labelled as "V1.0".
What if you and your friends want to have a go at writing some software together? Change control really helps with that. You can all check out files from the same master repo (this is where something like Github is very useful). When you have made your changes, you can check them back in again. All the code is kept in one place.
Each time you check in a code change, Git records who made the change. This can be very useful if a several people are working on the same software. If you find a bug is some part of the code, it tells you who was the last person to work on it.
Sometimes, two people might make changes to the same file at the same time. Git will warn you when you do this, but if the changes are in different parts of the file it will attempt to merge them together automatically. If it can't do that, you will need to look at both changed files and work out how to include both sets of changes into the new version.
Copyright (c) Axlesoft Ltd 2020