Git For Artists (and Other Non-Technical Folks).
So you’re getting started working with a team, and they are using git. What does that mean? What is git? How do I use it and why do I use it? These are all questions I had when I first learned back in my freshman year of collage. At first I thought it was just stupid, and I didn’t see it’s purpose. Flash to today, and I have more git repositories than I need, and I set them up for every project: large or small, team based or personal.
In this introduction/guide to git, I’m going to walk through what it is, why you would want to use it, what it’s good for and what it’s bad for, and how to interact with it. I am a game developer, so my experiences and guide will be focused towards game-devs, and more specifically towards artists and other non-technical people working in games. Although if these doesn’t descriptions doesn’t fit you, this guide should still work well if you are unfamiliar with git.
Before we get started, I just wanted to quickly go over some of the reasons I wanted to write this article. I am a programmer, with a computer science degree. My computer science classes introduced me to git, and I didn’t understand it, see its usefulness, nor get how to properly use it for years. Now, as a game developer, I interact with many non-computer scientists. I interact with many artists, writers, and other non-tech oriented people that all need to interact with git. I also am working on a game with my fiancee who is a fine-artist and has limited technical skills. I have had a hard time finding resources to jump-start someone into git. When I do find a tutorial, they often assume technical understanding above my peers. Or the tutorial gets right into the meat of HOW to use it, but never explains WHY to use it, or WHAT is going on in the background. By omitting this information, I believe that users that aren’t as strong in git skills often “skate by,” frequently nervous or frustrated or confused when interacting with git. They seem to struggle getting over this hump. I want non-technical people to have a resource that gives an overall understanding of what Git is, why you use it and how it works. Git is an intimidating and overwhelming thing to use. To really understand and get comfortable with it, you really need to use it. I hope to provide this tutorial in order to help non-technical people become more comfortable with git.
What is git? Why use it?
What is git? When I first learned to use git, my professor just said, “Okay, now go on Bit Bucket, setup a repository, invite other people, download source-tree, clone the repo, push a file, have your friend download the file, update the file, pull the update, see the update.” Blindly following these steps was not only confusing, but it seemed as though it was no better than sending my friend an email of a word document. They edit it and send it back, how useless.Well, this was just a terrible introduction to git, and if this was similar to yours I apologize. I think this kind of instruction makes it more confusing and less useful than it really is.
Basically, git is actually more of a protocol than a service or real product, and it’s broken up into two parts, the online component that you access through a website, and the downloaded software installed on your computer, which is called the “client component.”
The online part, is really very similar to something like Google Drive, One Cloud, or iCloud. It’s somewhere online, that stores any files that you want, and then you can access those files from any computer, so long as you know your login information. This is equivalent to an online git service such as: GitHub, GitLab, and Bitbucket. These services allow you to setup something called a “git repo” or “git repository.” Each git repo is similar to a Google Drive account. A git repo is really just a place where you put your files. Each Git account can have many repositories. Each repository has different levels of security. If private, a git repository is only accessible to those that created the repo, and those that the repo owners invite.
So if GitHub is equivalent to something like Google Drive, then what is the client portion that you have to install on your PC? Well, one of the many differences between git and something like Google Drive, is that you don’t really interact with the website. You use the website to set up the repository, check certain information ocassionally, or manage who can access the files, etc. However, to upload files, you actually use the program on your computer to upload the files to the repository for you, (not through a website). So if you want to upload a picture to your git repo, instead of logging onto the website and going to the repo, and dragging it in, you have the file stored on your computer and you tell your git program to “push” this file up to the repository allowing the whole team to access it.
So all in all, git is two pieces: an online portion that acts similarly to Google Drive and a client portion that allows you to upload and download things from the repo. However, if this was all that git was, it wouldn’t really be very special. As well as acting as a server to host your files online, git is a “version control" software. Basically this just means that as well as having all of your files on the server, they also keep every different change to that file that you ever uploaded! The best equivalent I can think of is when I work on a complex 3d model inside of Maya. Maya, while being a great program, is prone to making many errors, crashing, and losing lots of my work from weird bugs in the program. But also, many times I am at a base model that I’m happy with; I want to continue working on the model, but I’m worried that I might make an irreversible change or mistake that would compromise the file. This is why almost every time I save my file, I save it as a new file. This is such a common workflow, that Maya actually has a built-in hot-key to “increment and save” so that I’m never overwriting my older files. This way, if I make a mistake, I can load up all my files, see that I’m on version 23, and I can go back and check if things were working properly in version 22, or 21 for instance. This workflow has SAVED me countless times. Git, basically does this process for you, every time you push a file to a git repository. When you push a file to your git repository, it isn’t being overwritten, a new version of it is being pushed there. If you realize that something is broken, you can go back to earlier versions of the file very easily. This is particularly advantageous on large code projects, where you can keep track of what version of the files everything in your project is working as intended, if things get messed up, you can pretty easily look at the old versions and try and see what changes were made to cause these issues.
Along with the version controls, git can provide even more information to you. One tool shows what parts of the files are different between versions. This way you don’t have to scan a whole file yourself to see what’s different. Git can tell you explicitly, “you deleted line 35, and added this new line 76.” This makes fixing errors that were newly introduced quite easy to fix. Another feature is something called a “branch.” Basically, a branch is just a complete copy of all your files, in a separate safe space. You can do crazy things and really mess with everything in a branch, and once it’s working, you can bring all of your changes back to the original files. If you are never able to get something working, you can delete the branch and just go back to the original ones you started with. Another important tool is the ability to work with teammates on the same file. If I am writing code, and I am editing lines 1-20 of a file, and my co-worker is also editing that file on lines 50-70. We can both push our changes to git, and even though we both overwrote the same file, git knows how to combine both of our changes. If for instance, we did happen to both edit lines 1-20, whoever posted to git first will be considered the original version, and when I go to push my changes in later, it will alert me of the conflict between our changes, show them to me and allow me to manually combine both of our work together, or keep one of the versions entirely. These “merge tools” are incredibly useful for working in teams!
So that is what git is, it is an online server, that hosts your files, and all previous versions of your files. It provides tools to allow you to upload, download, modify, share, and revert your files. Now that you understand what git is, we can talk about how to use it.
Getting Started With Git
Setting up the Online Hosted Repository
To get started with git, there are two components, the online hosted repo, and the client-side downloaded software. First you will need to setup the online git repo, or if you are working on an existing repo, you will need to be given access and navigate to the page.
When getting started in picking an online host, there are a few mainline options: GitHub, GitLab, and Bitbucket. I don’t know all the differences to be honest, but I never liked Bitbucket, and I always found GitLab and GitHub to be pretty comparable. My personal preference is with GitHub. I’ll be using GitHub as my reference moving forward.
First, navigate over to your online host of choice, and click the “Sign Up” button to create an account. On GitHub, I believe that it will actually take you through a short tutorial using GitHub. You can follow that for more information. Once you get your account setup, you should see your home feed, and on the left-hand side there should be a “Repositories” section with a “New” button below:
From here you can come up with a repository name, set it to be public (accessible to anyone in the world!) or private (only accessible to you and those you invite), and you can create the repository! You should be taken to a page that has your repository details, as well as all your files. It should be empty at this point, but this is where your files will go for the project you’re creating!
Setting Up Your Local Client
Now, at this point, you want to download a tool that lets you use git on your computer (the client component). This way you can connect to your repository and push your files to the repo! So here comes yet another choice, there are many “git clients” as they are called, that you can download and use. Some of the most common clients I hear about are GitHub Desktop, SourceTree, and Git Kraken. Personally, I have never used Git Kraken but I hear good things. SourceTree I find to be confusing, it often doesn’t work properly, and causes loads of issues. GitHub Desktop I have used and find it to be a clean interface that is simple to use and get started with. So I would obviously recommend GitHub Desktop. I will be using GitHub Desktop in the future of this article for examples.
Note: You can also download and use “Command Line Tools” which allow you to use git from the Command Line. If you don’t know what the command line is, you can find it on Windows if you click the windows key (start key) and type in “cmd”. I will say that this is an advanced and more complex way to use git. This is how I, and many other programmers, interact with git. If you are unfamiliar with the command line, I would strongly advise that you do NOT start using git by using the command line. If you are interested, you can always learn to use the command line first. Once you have some familiarity with the command line, and a basic understanding of git, you could try transitioning over to using git from the command line to see how you like it.
So once you have downloaded GitHub Desktop, it will ask to connect to your GitHub account if you have one. However, if you are using a different git server than Git Hub, that is okay. Allow it to connect to your account, setup your name, email, and description to get to the main page of the program.
NOW. Here is where things are going to suck a little bit, and it’s going to get a little complicated. So in order to connect your local computer to the repository you made online, you are going to have to “clone” the repository. “Cloning” just means, take the online repo and copy it down onto your computer for you to use. Now the way that this used to be done was with an HTTPS link. You would click on “clone repository”, and supply the HTTPS link with a location to save it on your PC, and then it would just work provided you sign into the account with proper credentials. However, this method is not secure, and is being phased out. If you want to do this simply, you can try the HTTPS method, and if it works, feel free to use it. However it may stop working at some point. The new way that you connect to your account is with something called SSH. You can see that there is also an SSH link on your git repository.
Now you can take this SSH address and plug this into your GitHub Desktop client to clone from this address, however this will surely fail. The reason this will fail is because you need to generate an SSH key on the PC/PCs that you plan to be pulling to and pushing from. Then you need to take these keys and add them onto your GitHub account so that it can properly authenticate you pulling from the repository. Luckily for you (and me), GitHub provides a nice step-by-step tutorial on how to generate an SSH key on your PC and connect it to your GitHub account. You can view the original tutorial here. However, I will paraphrase, and take from this tutorial and add some information below. If you don’t wish to use their tutorial, or if you have issues following, maybe my altered version will help.
I want to stress at this point that the following steps are confusing and you are not meant to understand fully. There are a couple things I want you to know. First, you clone a repo by using the SSH address provided to you on the repository’s page. And second, the ssh keys we will be generating and linking are unique, they are used in place of a username and password. The SSH keys are a secure way for GitHub to authenticate what computer you are interacting with the repository from.
Step 1: The first step is to open a program called Git Bash. This should have installed with the GitHub Desktop client, however, if it did not download this, and go through all the installation steps.
Step 2. Once Git Bash is installed, open it.
Step 3: Paste the following text into GitBash and replace “your_email@example.com” with your GitHub email that you signed up with:
ssh-keygen -t ed25519 -C "your_email@example.com"And press the “Enter”/”Return” Button.
Step 4: After you enter this into Git Bash, it will ask you what file you would like to save the key in. Do not type anything and just click the “Enter”/”Return” button. It will then ask for a passphrase for the key. Once again, do not type anything in, just press the “Enter”/”Return” button.
This will generate two files on your computer. One called id_ed2559 and another called id_ed2559.pub.
Step 5: Now, you need to add this key to your ssh-key manager. To do this, type in:
eval "$(ssh-agent -s)"And press the “Enter”/”Return” button and it should give you back text similar to “Agent pid 59566”
Step 6: Finally, add the ssh key that you generated, to do this type in:
ssh-add ~/.ssh/id_ed25519This is adding the file that we generated earlier to the manager.
Step 7: So the file we just added was your “private key,” however, we now need to add it’s paired “public key” onto GitHub. It should be the same filename as before, however with the extension “.pub”. If you type in the following command and hit the “Enter”/”Return” button, it will copy the file contents onto your clipboard.
clip < ~/.ssh/id_ed25519.pubStep 8: Log onto github.com.
Step 9: Click on your profile in the top-right corner, and then click on the “Settings” button.
Step 10: There are many categories along the left-hand side, click on the one titled “SSH and GPG keys”
Step 11: Click on the “New SSH key” button.
Step 12: In the Title field, name this something that will help you recognize the computer, I personally have “Chris Home Desktop” for my home desktop, “Chris Aspire V Nitro” for my one laptop, and I even have another called “EGS workstation” for my computer that’s at the office I work at.
Step 13: In the “Key” section, click "Ctrl+V or right click and click “Paste” from the menu to paste in your key that you copied to your clipboard. Then click “Add SSH key.”
And while it took 13 whole steps, you now have your SSH key setup on your machine!
Now, from here, you can finally clone your repository successfully using SSH. So now you can go to you online git repository, find the SSH address, and copy it to your clipboard. Then go to your git client, and click “Clone” Then, paste in the SSH address you copied. Finally, tell the program where you want to clone the files to on your PC, note that this needs to be a folder with nothing already inside of it. If done correctly, it will clone successfully, if the repo is large it could take some time.
Using you Git Client to interact with the repo
We can FINALLY start using git! So now there is a folder on your computer that is an exact copy of the repository at the time that you cloned it! So if you navigate to that folder on your system, try adding a file of any kind, preferably something that you can update, such as a text file. Right-click and go to “New->Text Document” Add the words “First file!” and save the file.
Navigate back to your GitHub Desktop client and you will see that there is a section on the left that says “Changes” that will list all the files that are different from whatever was online last time you cloned. Your file that you created should be listed. You can click the check-box next to the file (if not already checked) and then at the bottom of the page there will be a section where you can supply a title, and a message. This is a title and description for a “commit.” A commit is simply you telling your local computer: “These are the files that I changed and want to send to the repository online, here is a title and description about what the file additions, deletions, and modifications are.” Once you fill in these details you can click: “Commit to main.” Main is the name of the main branch. Remember branches I mentioned earlier? Well you always are working on a branch within git, as each branch is just a set of your files and changes. You automatically start working on one called main, and you can make new branches at some point later on if desired. Once you commit the files, you will notice that your files still aren’t on the website! That’s because committing is just telling YOUR computer what things you would like to upload, but it hasn’t uploaded it yet.
To upload your files now, if you go to GitHub Desktop, in the top-right corner, there will be a button that says “Push origin”. Origin just means the repository that you connected to online. If you click “push origin”, it will push it online and everything should be visible on the website now! Now you can upload your files and it will keep all the versions you upload!
Using Git With Others/On Multiple Computers
So now that you can “push” things to the repository, you need to be able to “pull” things from the repository to your local computer. If you went to your computer at work, and wanted all your files from home, you need to pull them. Or if your coworker messages you that they updated a file and want you to look at it, you need to “pull” it down. So to pull, it’s quite simple really. In the top-right corner of GitHub Desktop there should be a button that says “Fetch origin”. Just click this, and if there is anything in the repo to pull, it should say “Pull origin”. Click it again. (NOTE: it may just automatically pull if it is able to, so you may only need to click once).
While this process is simple, it is worthwhile to have it’s own section, because there are lots of “soft rules” to pulling when working in a team. This is because of situations that can arise from people editing the same files at the same time. Imagine the following.
You are working on a paper, you write the intro, and then push it to Git Hub. Your partner pulls it down and edits the intro for you, they push this to the repository. The next day, you decide to start working on the paper again, and you start writing a conclusion. You go to push this online. Uh Oh! You never pulled the changes to the intro your teammate made! Git knows that you never pulled this, and knows that this is a problem because you effectively edited something that wasn’t up to date. What happens to the changes your partner made? Git won’t let you push until this gets sorted out.
If you remember from earlier, I did mention that in these situations there are tools that allow you to merge two changes. If it’s simple enough, git may be able to fix these two things on their own. Whatever the case, this is called a “merge conflict” which is when you are “merging” your changes with someone else’s. A merge happens every time that you pull in changes from the repository and put them into your working directory. A “merge conflict” happens when you are merging and can’t continue because there are changes on your computer and there are changes on the repository since the last time you pulled and it can’t figure out what to do with them. In these cases you need to: manually fix the issue, keep your version, or keep the repository version. However, try to avoid these things as much as possible. It is EXTREMELY hard to manually merge anything that isn’t code. Something like a 3D model or texture would be nearly impossible to manually merge as it is not a human readable file. Typically for complex files like this, I open both versions, mine and the one on the repo. To do this, I save my version somewhere else on the PC, and then I pull down the version from the repo. From here, I manually (in the program that I use to edit the file) copy over and duplicate work to the version I want to push up. For example, if it’s a Photoshop file that was updated, I would open the version in the repository in Photoshop and open my version in Photoshop as well. From here, I would look to see how they are different, maybe I notice that I de saturated the image, I would copy over the settings from my version into the new version to make sure that my changes were carried over.
The idea is that you want to avoid merge conflicts at all costs. This is where our “soft-rules” come in.
Rule 1: Always pull when you are about to start working. If you pull before you work, you are much less likely to run into any issues.
Rule 2: Commit often, and commit small changes. If you go through for a week and change every file and push it up at once, you will likely conflict with everyone. People were most likely pushing throughout the week and now your files are outdated.
Rule 3: Coordinate with you teammates to make sure that, as much as possible, you are never working on the same file(s) at the same time.
If you follow all these rules perfectly, you will never have a conflict (mostly because of number 3). But you will surely make an accident, forget to pull, overstep the files you were meant to touch, forget to push for a while, and you will run into conflicts. So don’t be too upset if this happens. Sometimes it is unavoidable and you just know that you’re going to need to do a crazy merge process. If it happens, try to contact someone who is more knowledgeable about git or the merge process. Try manually merging it if you can, and in the worst case, discuss the changes made with the other person. Find which is more critical/difficult to replicate, keep the more challenging version, and duplicate the work of the simpler steps. Hopefully you won’t run into merge conflicts, but if you do you will figure it out!
Congratulations!
You successfully setup a GitHub account, created a repo, downloaded a client, setup an SSH key, pushed and maybe even pulled your first files. That’s a ton an I’m sure that it’s overwhelming. As you use the program more it will become easier and easier to use.
Now, because this is a git tutorial specifically for artists, I wanted to go over how I think git could be useful to an artist. I have primarily used git for three things that are art related. One, keeping all modified versions of my art assets. Two, I have used it to host renders. Three, especially if you are using the artwork in the product, it is quite nice being able to keep all the RAW final art assets, as well as the project files all within git. For me personally, this is a much better/faster/easier pipeline than keeping the raw art in git, and the projects in something like Google Drive.
Best of luck with Git! There are many other features and tools that you can do for git. However, these are more complex and less frequently used. If you need to do something in git, just look it up and most likely you will find solutions for you. Doing this over a long time, lets you learn as you need, little by little, and you will become more and more skilled as time goes on.
