Git is often refered to as a source control tool. It’s useful both for teams working on a shared source code as well as individuals how wants a log of the changes in their sourcecode over time. While sourcecode handling is the most common use case, Git itself isn’t per say limited to just managing sourcecode and using Git repositories for non-sourcecode may also have value in your daily work. This post is a small apetizer of some of the cases I’ve been using Git for non-sourcecode.
Texts - Architecture, Designs, Documentation and blog posts.
In general most of my texts are either in plan text-format - or Markup. This “raw” format is well suited for being managed in a git repository. The “diffs” allows you to track changes in the text, if you’re multiple authors Git provide a place to have the latest authoritative version of the shared text.
All the posts for this blog is also located in a git repository in markdown format. Once I have a server with Hugo installed, installing this blog is mostly a matter for cloning the repository, runing a setup shell script and everything should work without further fuzz.
I run some servers, which are either based of a standard VM-image or a container. Most of the software are installed from standard repositories (provided by the Linux distribution) and installed using a recipie which is often created as a simple shell script once the server is spawned the first time.
I many cases, I’ve created repositories named after the machine, and replicated the directory structure to the extend the structure include configuration files or content for the utility of the machine. Every time the machine is changed, a small script updates the files from the machine into the git repository.
Having a small set for core shell scripts - to install all the (software) packages needed and restore all configuration files, allows me quickly to recreate a given machine from the repository without having a binary backup and mange this.
Once the “backup” git repository has been created, it’s often fairly easy to validate that it actually works, by installing the files into a local docker image - with the same OS as a base.
My shell configuration files
I like working in the shell and do it quite a lot. Doing this has created a bunch of dot conf files - small configuration filer located in my homedirectory on the machine I work. This suite of files also lives in a git repository, which allows me to quickly bring all configuration and shortcuts I need, to any new machine. The only hassle is naturally to make sure they are updated when changes are made - both to the repository and propagated to the machines where the suite of configurations are deployed and used.
.. and beyond
Git is mostly suited for text-based content, but can handle binary content as well. If you venture into this domain, you may need to add some extentions and plugns to Git, as it can vastly improve the user expirence with tools beyond what exists in baseline git.