You might be wondering how my process of releasing FOSS projects works. FOSS (free and open source software) is an essential part of the modern world, and the stuff I write isn't targeted at a paying demographic. I go through a simple process of releasing software that involves 'git', GitHub and ForgeJo. I don't host anything on forgejo.org, but rather I host my own forgejo server.

Prior to GiT, most (if not all) version control systems were centralised. There was a single central repository for a project, and the server software controlled who got to edit files and when.

GiT is a distributed version control system. Everyone and anyone can get a copy of the main repository, simply by cloning it. They can then edit any file they want, and within their own copy of the repo they can track changes and perform roll-backs to any point in time, right back to when the original repository was created. If they have been given the rights to do so, they can push their edits up to the original repo (note I say 'original' and not 'central', because the idea is that everyone has an accurate copy of the repo).

If they don't have rights to push, they can send a pull request to someone with rights in the original repo, and if they agree the changes are ok, they can pull changes from the satellite repo.

It's a nice and fairly safe system, that along with the granting of rights to do stuff to manage the repo makes it very flexible. The person owning a clone repo has the ability to state who has access to their clone and what those other people can do - in other words, they have all the rights to grant rights on their clone (and only their clone) as the person who the owner of the original repo.

After installing git, creating a repository is as simple as typing 'git init' at the command line.

GitHub is one of a number of sites on the web that allows anybody to create a repository on their servers, and keep full control over it. For FOSS projects, this service is provided free, and allows other programmers to join the project, and end-users to access the repository.

First you create a project on github, then point your existing repository (on your hard disk) at it, telling it that the remote repo is the 'upstream' repo. After one or more commits of your changes, you can 'git push' all changes in your local repo to the upstream repo. GitHub even provide a GUI applet (that you can also install on your phone) to make this process even simpler.

The source-code for github was originally FOSS (and most of it still is), so people were able to 'fork' the repository and get all the source. Forking is like cloning, but creates a new origin, and this allows people to create a variation of github that better suits their purposes. One of these forks became known as 'GiTea' (GiT with a cup of tea). ForgeJo is a fork of GiTea.

I host a ForgeJo server on my central intranet server NAS. It looks very similar to the github interface (deliberately so), and I generally prefer using it. However, it's my intranet server, and I'm certainly not going to let anyone access my network or anything on it (apart from a couple of OpenSimulator servers, but that's another story).

Edit: I've now moved my ForgeJo server and repositories onto my shiny new Argon EON NAS

I've been programming since the early 1980's, and have been a professional programmer since the mid-1980's. In all that time I have only ever had to roll-back code when someone else made a stupid error. I'm not infallible, but I've never had to roll-back my own code. Keeping a local repository then, would seem like overkill. Here's something a lot of people don't know: Hubris goes hand-in-hand with Karma. The reason I haven't had to roll-back is precisely because I'm prepared and have the ability to do just that. If I deleted all the history data from a repo, it won't be Murphy's Law that says I'll need to roll-back in the very near future, it'll Karma.

The next level of security is an on-site backup. Effectively you are copying your work to another machine. The last layer in the onion is an off-site backup.

Backups are different from roll-back history. In the past it was necessary to make copies of your work, even if you stored them on the same disk, because disk technology wasn't so great back then. Git repositories are a recording of all the changes you have applied to your work, and the recordings are stored in such a way that they can be applied to change the files back into a previous state. If you want a backup of your work (and all that roll-back history), then you have to make a copy of it. Git makes this extremely easy.

Firstly, I create an empty repo and add some files to it. There will probably be other stuff I want to do to configure the repo. Then I head over to the ForgeJo server on my intranet (via a web browser) and create an empty project of the same name.

Next up, I issue a command to tell git that there is an upstream repo:

git remote add origin url-to-upstream-repo

ForgeJo will require I present credentials whenever I try to upload to the repo, so I add these the local git repo so I don't have to bother typing them out every time.

Whenever I've finished editing stuff, I do a commit to my local repo, then do a 'git push', which will send the commit data up to the ForgeJo repo.

Sooner or later, I'll want to make the project available to everyone, and github is where I usually do it. So now it's time for the fun stuff.

Stage one: I create an empty repo on github. Stage two: I delete the ForgeJo repo on my intranet server, and create a new empty repo of the same name.

I'm not finished yet though. On the ForgeJo repo, I can add a 'push' repo, so this is where I add the url for the github repo. I have to add a secret key too, so the github repo knows the push is coming from me. I set the repo to push changes to github as soon as the ForgeJo repo changes.

Stage three: I delete the hidden '.git' folder in my local repo, and do another 'git init' and add my credentials to the ForgeJo repo again. What I've done here is effectively thrown away all that lovely roll-back history. You can be sure I take a backup of the entire repository before I do this.

I add all the files again ('git add .'), set the main branch and perform a commit, then 'git push'. This will send everything up to the ForgeJo repo, which will the push everything up to the github repo. If I ever edit/commit/push again, both the ForgeJo and github repos will update too.

When it comes to making releases, I am only really concerned about that on github, so I create a tag on the ForgeJo repo, then create a release on the github repo using the newly created (and pushed) tag.