Everything you need to know about Git in games development

The market for version control – an integral part of games development – has gone through a lot of changes in the past few years, one of the biggest being the popularity of Git, an open source distributed version control system originating from the Linux community but now used by developers in all kinds of organizations worldwide, increasingly including games studios.

It has a lot to commend itself: it’s cheap, fast to get set up and gives developers rapid, flexible version control, so it’s ideal for start-up studios and small teams. However, Git can become cumbersome when teams or projects scale up, it lacks security features, it is not optimal for handling binary assets like art, plus it does not give management adequate visibility and control.

Its limitations are not hindering Git’s exponential growth, particularly with students leaving the education system already using Git. Fortunately, many of its limitations can be addressed with the help of a few tools and techniques.

GIT MANAGEMENT TOOLS
Perhaps the most widely-known category to date is Git management tools such as GitHub, which while perhaps the best known, is far from being the only one. Git management tools give users a common place to store all the Git repositories that are created and in theory, makes it easier to manage them, while introducing some features that aid collaboration.

Git management tools can also improve Git’s security, which matters, because Git’s architecture does not include security beyond a verified history, with no authentication, permissions or access control.

MANAGING SECURITY AND SCALE
The degree of security Git management tools can provide varies considerably. Some may introduce a very basic level of security, with access to all files at the repository level, so users can either access all files or no files. There are other tools that do provide more fine-grained access control – plus visibility of users trying to access those files.

Again, the level of granularity varies, but it is possible to have access control across IP address, user, group and with enforceability at code repo, branch, directory or individual file level, whether locally or across authorised locations. Also, depending on the tools being used, additional protection can be provided by the fact that they do not expose Git to the ‘outside world’ and reject commands unless they are a specific set of whitelisted commands associated solely with the software tool being used.

Another point to consider is that while Git is perfectly fine for small teams and projects, it rapidly becomes unwieldy when those teams and projects grow, which is so often the case in games development. This is no criticism of Git, it’s just the way it is designed: a Git repository is organised internally as a tree where each node represents a change to a set of files, cryptographically secured to its previous change. Each repository requires its whole history to be present, so downloading (or cloning) so as a project grows, that can take minutes or hours, as opposed to just seconds.

Once configured, a Git repository cannot be split up. An alternative is to have multiple repositories, but this approach brings its own problems, with hundreds of Git repositories that are hard to manage, with no single view of the whole project and creating what is known as ‘Git sprawl’. Sure, it’s not impossible to stitch all the repositories back together again, but that requires a lot of extra work and – in organisations that try that – it’s not uncommon to have people dedicated to doing just that, completely negating the low-cost of Git that may have encouraged its adoption in the first place.

Git management tools will help to some extent, plus there are now tools out that can retrospectively be added to the Git environment to break down a project into smaller chunks, known as ‘narrow cloning’, though it is necessary to factor in the additional processes, supervision and cost that will introduce.

BEST PRACTICE
There are more techniques and tools that games studios can use to help manage Git and these apply to version control in general, not just Git. For example, it’s good practice to work on small intervals: the chance of merge conflicts or invalidations increases on long-lived work on a separate branch when developers modify shared files. Also look at code review tools, which can significantly improve team collaboration: the more people look at code, the higher the resulting quality, plus everyone has some knowledge of the whole codebase.

Continuous integration is useful for validating any push into the shared code line. Each pushed change should be verified to ensure the shared code line is always in a good state, otherwise tracking errors in future changes becomes very hard.

BINARY ASSETS
Games development inevitably a wide variety of binary files – graphics, animations, video, audio – often large, across different formats. Binary files are not easy to version in Git (even GitLFS use will lead to large volumes of asset updates), so organisations often store binary assets in other systems. This is not ideal because in games development tight collaboration between all contributors – notably artists and developers – is important. Also, for any organisation adopting Agile, Continuous Delivery or DevOps development methodologies, having a ‘single source of truth’ for everything associated with a project is fundamental. Plus, Git does not inherently maintain an immutable history, which may be important if it becomes important to roll back to an exact, previous version, for instance, to deal with bugs.

Fortunately, a new breed of Git management tool has emerged, which support new ways of working. These hybrid systems support both Git and other version control tools, across distributed and centralised version control, while also enabling management to have better visibility of the entire development environment, across all contributors, locations, files and systems. In other words, it is a way to carry on using Git, but without sacrificing the ‘single source of truth’ aim.

Git has its merits and it is not going to go away anytime soon, so embrace that fact, but look at ways in which to deal with its limitations around cost, security, speed and complexity. Fortunately, new ways to manage and enhance Git-based development environments are emerging and those will continue to evolve.