More than a year ago I wrote a guide about Git and how to use it effectively in Unreal development (see links below). That guide is valid today, since Git does not change very much, and version control is always really important for any developer. One thing can be problematic - where to host your repository. There are numerous online repositories available in the Internet. Some of them have free tiers, which have usually very limited features. Even if you pay monthly fees, the repository size may still be very limited.
Git Basic Operations in UE Project (In the end of the newsletter)
Text-based code (e.g. C++ or C#) is not a problem since they take very little space, but game development projects have usually lots of binary assets, like images, 3D models and other binary source files - regardless of game engine used in project. In addition to that, Unity, Unreal Engine, Lumberyard, CryEngine, Open3D Engine and other game engines usually have their own specific binary files. As an example, Git handles Blueprints of Unreal Engine as binary files. These binary files take much more space, and Git usually cannot compare what has changed, so it stores every iteration of a binary file as a new binary file. Eventually the repository can grow very large in size, to something that would cost really much on a hosted service due to its size in gigabytes.
Self-Host Your Git Repository
One option that people often forget, is to self-host your own repository on your own server in your premises. This is easier than many think, although you need some extra technical skills, but anyone with moderate Linux experience should be able to handle it. Like any solution, self-hosting has some pros and cons - they are just opposite of leased hosting.
Pros of self-hosting
No repository limits
Fast transfer
No transfer fees
No monthly upkeep fees
Cons of self-hosting
You need skills to administer a Linux server
You need some extra time to upkeep the server and repository
If developers work remotely, then you need to handle security issues
You need one extra PC
You need external hard drive for repository backups
Most important advantage is that there is no limit how many and how big projects you store. Pushing and pulling is usually very fast when your server is in the same building. Data transfer will cost nothing and there are no monthly upkeep fees.
However, it is not totally free. You have to devote certain amount of time for routine administration. Usually this is perhaps one hour in a week, but occasional hardware problems can take few extra hours. It is possible to automate some, but not all routine administration tasks.
If some of the developers work remotely, you have to expose your GitLab server to the Internet. This means configuring your router and also handling security issues like SSL configuration, firewalls etc.
Most importantly you need skills for this, but administering a linux server and Git repository is not that difficult if you really want to learn it. So… how to do it?
GitLab to the Rescue!
My solution has usually been to host my own repository, on my own server, using GitLab. This can be done in two ways, either use virtual server on services like AWS or Azure, or set up a real server in your studio. When we are talking about a small team, or a single developer, almost any old PC is sufficient for this purpose, and in many cases it is not necessary to keep it running all the time, unless there is really intensive use.
Minimum specs are quad core CPU, 4 GB RAM, and at least 200 GB disk (it does not have to be SSD). I have occasionally used old laptops as Git server. Don't put too much money on hardware, it is more important to buy separate removable hard drive for backup purposes. Your sourcecode is more valuable than the hardware, so you should invest in proper backup procedures.
Set up your server
There is not much difference whether your server is in the cloud or on the location. Installation procedures and management are quite similar. Linux is an obvious choice, and I recommend to install Ubuntu LTS. It does not matter if you choose desktop or server, but desktop version is perhaps easier for those, who do not have long experience with Linux. Installing Linux is really easy nowadays, and there are lots of tutorials and learning material available. As a sidenote, you can run GitLab also on Raspberry Pi, but then I recommend using Pi 4 with enough RAM.
When you have Ubuntu installed and running, the next step is to install GitLab. This is done from command line, and you can find the instructions on GitLab webpage. I don't quote them here, because they may change. You will be installing GitLab EE (Enterprise Edition). You would need a license to use its EE features, but it does not matter, since without licence it does function as community edition as long as you want. Later, if you want to use those EE features, you have to only purchase a license, and activate it. However, the community features are more than sufficient for single developer or small team - all the important features are there.
GitLab has excellent documentation itself, so I will only highlight the most interesting features. I am not trying to recreate documentation, but I will try to show that GitLab is a good (and free) option for a single game developer or a small team due to its numerous features and relative ease of use.
Server Administration
At its minimum, server administration tasks follow a routine pattern like this:
Weekly server updates
Weekly GitLab backups
Server updates are quite easy to handle with Ubuntu system tools, and it is possible to automate them. I take GitLab backups with commandline scripts, and it happens in two parts. First GitLab makes a backup dump of its database. Then I will move that backup and copy certain other files to external disk. If my GitLab server crashes beyond repair, then I can recover it from backup. I just need to install Ubuntu on another PC, then install GitLab, and finally restore that backup.
Actually, it is possible to restore Git repository from any up-to-date Git repository on any users workstation. Git is decentralized, which means that each Git repository contains all relevant data and history. But GitLab contains other data, not just Git data. GitLab is Git server, and it is a project management server, too.
Project and User Management
GitLab is quite easy to manage, since it is web based. You just open the web page of the server and log in. It supports SSL, of course. You can control most of the day-to-day functions although occasionally you have to manage updates etc on Linux server itself.
Primary function of GitLab is to provide an easy-to-use git server, of course. As such, it provides all normal Git features like branching, push, pull and repository history. But GitLab is not only a Git server, it is also a well featured project management tool, and that is why I favor it, because it provides all the features under one roof.
Project management on GitLab is quite self-explanatory. You create users and teams, designate users into teams with different roles. Users can create projects for themselves or for teams. You also have many other features like email notifications, issue tracking, code snippets, milestones, time tracking, Discord integration, integrated code editor and even wiki, where you can upkeep design documentation etc.
Starting a project
GitLab has good documentation, and creating new project is very easy, but there are couple of things new users should understand. First of all, you should use quite new Git version on your workstation, to avoid certain inconsistencies in the way a new repository is created.
Second, creating a project in GitLab and creating the repository are two different things. You can create a project in GitLab with no code repository (Create Blank Project), and remember to take check mark off in option Initialize Repository with a README (because you will push code from your workstation).
Third and quite important thing is to have a gitignore file in your project root. Gitignore file tells to git what files should not be tracked and uploaded into repository. Those are usually temporary files, or derivative files which are regularly created from other files. There are gitignore templates available, but you should modify them to your own needs when necessary.
Now you can upload the code from your workstation and create the appropriate code repository. You can find command line instructions in the project page which you created. This is how you normally proceed on Unreal Engine (and other game engines like Unity etc.) projects, because Unreal Engine editor creates the file structure for your project.
Self-hosting a GitLab server is not that hard it may sound. It is easy to practice on your own server, because if you make some mistakes, you can always start from beginning. I have used GitLab for more than 7 years now on day-to-day basis, and I’ve found only couple of serious problems during this time. Every one of them I could solve quite easily using documentation. Trickiest part may be the SSL certificate configuration which you need if your GitLab server is exposed to Internet, and certain other security issues. In some cases only certain types of connections may work due to your SSL connection. Based on my experiences I can recommend GitLab as a good self-hosting option for a game developer.
I might have a look at installing GitLab - but I'm not sure if the additional features are worth the complexity and dependencies on SES (Someone Else's Software), given that we already have "on-premises" git repos that work just fine.
I fully accept that for someone with limited Linux experience a graphical GitLab option could be attractive.