Git for Creatives: Versioning and Backups for Beginners
Are you a writer? Digital artist? Any kind of creator who relies on digital systems to save and store your work?
If you are, then you might benefit from using Git. Why? Well, what if I told you that there's a system that is resource-lite, that saves your work, that saves a record of each version of your work (so you can retrieve old, in-process versions of pieces whose directions you might wanna go back on), that is nondestructive, and that you can use to back up your work on external sites so you don't have to worry (too much) about keeping that work safe?
That's Git.
Git is version control software originally developed by Linus Torvalds to assist him with Linux development. As in, the development of Linux. It's open-source, free as in free, and free, and it doesn't require too much technical knowledge. It uses its own algorithms to store archives of changes you make to the files you instruct it to track. Think of it as a camera that captures your work at specific times during its creation: from a sketch, to lineart, to a colored piece, to shading. Rather than save each file individually, it just records the differences between one picture and another.
Because Git is such a widely-used system for software development, there are a ton of sites you can use to host (or store) your Git repository (repo), usually for free.
If you're interested, then read on, and I'll walk you through downloading and setting up Git, including use examples, through to pushing changes to GitHub.
Step 1: Downloading and Installing
This is the easy part, so I won't say too much. Go to the Git site here, select your operating system, and follow the download and installation procedures for your particular OS. You can also access it through winget and any other package manager. If you're on Linux, it's probably already installed with your distro!
I'm on Windows, so my guide is gonna be tailored more for Windows OSes, but the general steps will be the same for any OS.
As you go through the installation process, at one point you'll be asked if you want to add "git bash" to your context menu. You should agree to this to make things a little easier. You by no means have to, but it's just a nice shortcut, especially if you don't really feel like messing around with your terminal that much.
I'm gonna proceed with the following assumptions: you're on a Windows-like system, and you've got a Git Bash option in your context, or right-click, menu. These steps should be easily adaptable for your specific setup, however. Just keep these assumptions in mind as we proceed!
Step 2: Using Git
Git doesn't really have a UI. Well, it does, but it's not super helpful, especially for beginners. So, you should mainly use Git through a command prompt or terminal.
That may sound daunting if you're unused to using the command prompt, but trust me, it's a lot easier--and harder to fuck up--than you probably think.
I'm getting a little ahead of myself, though! First, open the folder where you store your creative work. If it's spread across folders, you may want to consolidate. Either way, go to a folder (hereafter called a directory) that contains a body of work that you want to control. In this context, "control" basically means that you're handling it through a versioning system like Git.
You want to open the highest-level directory that contains your work, and you want that directory to contain only that work. For example, my setup looks this:
The directory I use is Writing, which is in my Desktop directory. I have individual directories for Drafts, which then, once complete, either get moved to Submitted or Complete, depending on what happens with them. What's important to note is that all of my work is contained in subdirectories of the Writing directory.
Also note that the .git folder, created as a part of using Git, is a hidden folder. You don't have to turn on hidden files and folders to work with Git, though--just know that if you don't, you won't see it here!
When you're in the directory that contains the work you want to control, and only work you want to control, it's time to access Git!
You can right-click in the directory, then select Show More Options, then select Open Git Bash. You don't need to do that--you can open a command prompt here, or open one anywhere and navigate to this folder. This is just a nice shortcut that keeps me focused on the Git process, without getting distracted.
Step 3: Adding Files to Git
When you open Git Bash, here is what you'll see:
If you're unused to working with command prompts, seeing a blank one staring at you like this can feel daunting. But it's super easy to use, and it's much harder to mess things up with a command prompt than it is with a GUI. Trust me.
Okay, but why did "Open Git Bash" open a command prompt? Well, "bash" refers to "Bourne Again SHell," a command interpreter and language designed specifically for UNIX systems. Put incredibly simply (and somewhat incorrectly), it's a programming language you use in terminals. Opening a bash instance opens an environment wherein you can use bash--a terminal, or command prompt. On Windows, it ensures that you can use the same syntax as everyone else without problems--because everyone else is using it.
With Git, you only need to know a little bit.
First, you need to tell Git what you want it to control. Typically, you'll want it to control everything in the directory you're using for your work. (For programmers, this isn't always the case. I'll also go over making a .gitignore file later in this post, so you can add exceptions. For artistic purposes, that should be enough.)
First, in the Git Bash, enter:
git initi
Easy right? But make sure you do it! This creates an empty repository (more on that in a bit) so that you can start working. (I forgot about this step at first! Thank you @vakavanhasaatana for reminding me!)
git add .
Yes, include the period! Why?
Let's look at the entire command. It should be easy to parse.
git: This is short for git.exe, which is the program you're accessing and giving commands. Just as you can't use a program without opening it, you can't give commands to a program without telling the computer which program to use.
add: This is the command you're giving Git. In this case, you're telling it to "add" to the repository--that is, the entire record of Git's control, including its ability to reconstruct your work--whatever you specify in the next part of the command.
So at this point, you're telling Git to add files, and it's expecting you to tell it which files.
Believe it or not, that's what the period does.
Put simply, the period serves as indirect shorthand that means "the current directory." Similarly, were you to use git add .., you'd be telling Git to add everything in the directory one level above this one, or its parent directory. That's just because ".." means "this directory's parent."
(Note that this is not an absolute path! If you access Git while the prompt or bash is open in a different directory, "." will mean THAT directory. For reference, my directory's absolute path looks something like this: C:\Users\gaast\Desktop\Writing. You shouldn't need to know this, but it can save some confusion if you make a mistake somewhere!)
At this point, after you press Enter, Git will create a repository that includes every single file in this directory and every one of its subdirectories. But that's all it does! So, let's move to the next step.
Step 4: Making a Commit
You've now added everything in this directory to a Git repo. What that actually means is that you've told it to look for every file that has changed since the last time you added files to the repo, and to keep them in mind. Because this is the first time you're using it, it's adding everything, but each subsequent time, it will use this command to parse which files have changed between this use and the last commit.
What's a commit? Going back to the photography metaphor, a commit is an individual photo that captures the changes in your files. Using "add" is looking through the viewfinder; making a "commit" is pressing the shutter button. This part is what locks in your changes, so make sure you do it!
That said, you can keep adding and adding, and keep Git waiting and waiting, until you're ready to commit every change you've made. That's useful for programmers, but I can't figure out how helpful it'd be for artists.
...Anyway!
To take that snapshot, to lock in and save your changes, use this command:
git commit -m "Commit comment."
The quotation marks are integral! I'll explain why in a second. Let's break this command down:
git: Same as before!
commit: This is the command you're giving Git. You're telling it to save every change in the files you've added.
-m: This is best thought of as an option. You have the option to write a commit message in the Git Bash, and, by including -m, you're telling Git that you're making use of that option. Whatever follows this declaration is the commit comment.
"Commit comment.": Git requires that each commit have a comment that, ideally, describes the contents of the commit, that is, the change between the new snapshot and the previous one. This is for a lot of reasons that are more relevant to programmers, but hey, you can use this as a little journal describing what you've done, how you feel about it, whatever. You'll be able to access these later!
So, you could theoretically enter just "git commit," but Git would then try to open a text editor like Visual Studio or something to try to force you to give it a comment. So just use the above syntax so you don't have any problems.
Oh yeah, I told you I'd explain the quotation marks. You put your comment inside the quotation marks to indicate that it is a string. In computer parlance, a string is essentially textual data that isn't supposed to be used as a command, switch, option, whatever. When you enter names into Oregon Trail, you're giving the game strings of data. Basically, using these quotation marks ensures that Git knows that what you're writing here is semantic text, not anything else. So make sure you have them!
And with that, you're done! You now have an up-to-date repo that contains all of your work. Nicely done!
Whenever you're done working for the day, or the session, or whatever cadence works for you, follow all those same steps. Open the directory, open the Git Bash there, enter "git add ." then "git commit -m 'Commit message.'" And that's all you need to do.
I'll go over some other commands in a bit, but first, I promised you a backup, didn't I? I'll get there, but first...
Step 5: What You Have and Haven't Done
You have your repo, and that rules. You can now access any version of your work that you've saved through Git with some commands I'll teach you in a bit.
But there's a lot you HAVEN'T done, too. What haven't you done? Well...
You haven't saved every file every time you've saved it. You have ONLY captured the SPECIFIC save you gave to Git.
You haven't backed up your repo, and it could still be lost if you lose this directory.
I can't stress enough how much like a snapshot a Git commit is. Think of it like time-lapse photography in this case. In time-lapse photography, the camera takes a picture, waits, and then takes another picture. Whatever happened in front of the camera in between those two pictures is lost--the camera doesn't have it. It's not in the pictures.
Let's say you're sketching something. You save it, get called away, and quickly commit the change beforehand. Then you come back, finish the sketch, save your progress, then move onto the lineart. You save that, then commit it.
But--oops! You accidentally drew the lineart on the sketch layer. Shit! Well, you can just revert back to the previous save, the one with the finished sketch but without any lineart. You go to access that data in Git and... it's not there! It's not there because you never committed that save of your art. I hope you can Ctrl+Z back to it!
Git is only as effective as you are at using it. You can't expect it to rescue work you haven't told it about any more than I can get my camera to take a picture of the stuff it missed.
But hey, come on, where's the backup info?
Well, I just want to stress first that all you have right now is the ability to version your files. You can access everything you've saved with it. But it's still local, sitting on your drive and its storage.
If you save all of your work on a cloud storage platform like Google Drive or OneDrive, then you can access your repo with any machine that can access that cloud storage account. That may be all you need! But let's say you really rack up data, and a cloud account won't cut it.
Step 6: Pushing to GitHub
GitHub, sadly now owned by Microsoft, is a site designed to host Git repos. It is a community of open-source software and developers, and, despite Microsoft, still mostly rules.
I'll teach you how to back up your work on it for free.
First, create an account. Obviously. It's free!
Then, create a new repository. It should be a green button that says "New" under a heading that reads "Top repositories," which will be empty.
Give it whatever name you want--"Art," "Writing," whatever. You can give it a description if you want. The only thing you have to pick is whether you want your repo to be public or private.
Now. This is very important.
If you make your repo public, you need to know that EVERYTHING in your repo will be available and accessible to anyone in the world, with or without an account.
If you select this option, as a writer, you will lose first-publication rights. I dunno if art works similarly, but if you're trying to sell your work, you probably shouldn't give it away for free. GitHub operates on open-source licenses. Anybody can copy, download, and edit your work*.
If you select this, make sure your name, email address, and any other information that could identify you is scrubbed from your content. Do not make your repo Public unless you know what you're doing. If you're reading this guide, I can confidently say that you don't.
If you make it private, only you or approved others can access it. It will be behind walls. You won't lose first-publication rights, and you don't need, though probably should in the case of data breaches, to remove your identifying info. So make sure it's private, okay?
With that, just select Create Repository.
The page that opens next will be your repository. GitHub gives you three options for how to connect your local repo with this one. Use the bottom example:
In Git Bash, enter those commands in sequence, changing them to be specific to your URL. So first, enter the git remote line, then press Enter, then the git branch line, then press enter, then the git push line, then press enter.
Make sure you have the Bash or command prompt open to the correct directory!
Once you've done this, refresh the GitHub page, and you should see a replica of your repo's top-level directory.
You may need to include more information, though! You'll have to add your GitHub credentials at some point so it knows you're authorized to access that repo. It should be self-explanatory.
From this point on, whenever you're committing your work, after your git commit command, enter this command:
git push
Push: Send the new repo state to GitHub and update it there.
This is what backs up your content! You can also now access that repo wherever you can use Git and include your GitHub account's information. How? Try it out!
Make a new directory anywhere--maybe call it "Example." In Example, open Git Bash. Now, enter this command, replacing the URL with your URL's repo:
git clone https://github.com/username/repo.git
Get that full URL in there, then press Enter! Depending on whether you've configured Git with your GitHub credentials on the machine, you may need to add that information, and then you should get a perfect copy of your entire repo inside Example! And you can work with it just like you always have.
I think you can imagine what "clone" means.
*And that can be a good thing! You can work collaboratively with people. Maybe you want that! Just practice good safety. If you want to learn more about how to use GitHub as a collaboration tool, I encourage you to find more resources about GitHub itself. I'm not a source for that!
Step 7: Loose Ends
First, let's talk about a .gitignore file.
A .gitignore file is a plain-text file that tells Git what directories not to include in the repo, even if you would otherwise catch it with the add command.
To make one, open a text editor like Notepad, then add the directories you want Git to skip over adding. In my case, my .gitignore just has "narrat/demo" in it. Don't use quotation marks, and make sure you use a forward slash. Add one directory path per line!
(The directory automatically assumes the current directory, so just add the directory and any subdirectory names without using ".".)
Now, I said you could see your commit comments. To do that, in the Git Bash, enter: git log
Use the scroll wheel or arrow keys to scroll. To get out of the log, just press Q.
And now, to access an older commit:
I actually don't know how to do this. And don't wanna give any misinformation. So please look it up on your own.
Look. I'm getting high. I'm bored. I've been working on this for over an hour.
Give me a break, okay?
Anyway, bye.