Git Gud: F the command line

Git, the Dark Souls boss of Games/Apps Development

Real quick, what does the prototype do again?

• Real life subtitles!

For this project I acted as lead programmer to get Morgan to implement this prototype. I unstuck him if he had questions, helped with small bits of implementation, and guided him further along the git process. We’re taking the project further, so I’d like to address a huge issue I’ve seen in the industry with this writeup:

The fact that Creatives are usually kept out of the git process.

Overview

1. Why Creatives aren’t allowed in repositories

2. How to use this page

3. Create a git project

4. The git process

5. When the git process fails

I believe all Designers, Artists, and Developers of any kind should know and be familiar with the git process. Why? You build better.

There is joy and security in knowing you can contribute to the projects you are building, both for you and your teammates. With the industry changing rapidly, and a change-of-guard desparately needed finally starting to happen, I’d like to see the future of the industry created and led by people who enjoy and support each other in the trenches :)

I've convinced management to let me teach creatives the git process on company time. I've convinced engineers who otherwise staunchly believe creatives have no place in git. And I’ve personally taught over a dozen designers and artists, on company time, at game jams, on side projects.

This works.

Why Creatives aren’t allowed in repositories

No matter who you are, you will break your project. This is why you’re not allowed in the code repositories at work.

But if everyone breaks the project, how do Engineers keep building? Engineers are taught to use git, so they know how to unbreak the project. Designers and Artists are not taught, so they don’t know how to unbreak the project.

That’s it.

It's not complicated, you don’t need to ever touch the command line, and it’s not an engineer-only thing.

Git, and the git process specifically, lets you continue building what you want to build even when you break the whole project. If you read this whole piece, and practice it, you’ll be able to learn to contribute to any project at any company (different companies have sometimes more, or less, or just different processes/software/etc in place. But fundamentally all the same thing)

How to use this page

You always exist somewhere along the process below. Just find where you are, and read the next step. If you don’t know a word, ask AI to define it.

Side Note, here’s some keywords that you should go read about later:

• Game asset management: literally google drive + naming convention is the entire solution unless you’re a massive company

• Large File Storage

• Different branching patterns

• Multiple projects in a single repo

Create a git project

1. Download Github Desktop and create a Github account

2. Open Github Desktop and follow on-screen instructions for setup. Do defaults if/where asked

3. Create a New project

   1. On the Github website hit the green New button

   2. In the creation page, initialize with a .gitignore file that corresponds to the type of project you’re doing: Unity/Unreal/Whatever. Crucial to do this.

      1. Ask AI for what a gitignore is if you want

4. Clone your git project

   1. This just means downloading the git project files to your computer

5. Create your AR Project

   1. Unity, Unreal, TypeScript + React, whatever: Name the Unity project the same as the Github project, then put all the Unity files into the Github folder —> Push the commit on Github

The git Process

1. In Github Desktop, create a branch and name it like one of these 3:

   1. prototype/your-prototype-name

   2. bugfix/your-bugs-name

   3. feature/your-feature-name

   4. Explanation

      1. There are 3 types of work you are ever doing: Prototypes, Bugfixes, and new Features. Name your branches like this so you don’t have to guess which branch is for what.

   5. Examples of good names:

      1. bugfix/fixing-loading-screen-hidden-issue

      2. feature/menu-screens

2. Click Publish branch

3. Make changes for only what you’re working on

   1. Part of the git process is being intentional with your work. Only add/change/remove things from your project that help you get your current task done.

   2. Always check in Github Desktop what you’re pushing. Never commit something if you don’t know what it does.

4. Once you’re happy with your changes:

   1. In Github Desktop write a summary for your changes

   2. Click Commit

   3. Click Push

5. Eventually, when your task is implemented or your bug is fixed, you want to bring all your changes into the Main branch:

   1. Go into Github Desktop

   2. Click the blue “Create Pull Request” button

   3. Fill out Pull Request info in the website popup

6. Tell someone to review

7. If you’re the person reviewing:

   1. Do your review, then at the bottom

   2. Click Squash & Merge

      1. A way to merge git branches so that when reading the commit history, all commits from one set of work on your working branch are contained within 1 commit submitted to the main branch. Contains bugs and features in a safer way than regular merging, which would display each commit separately.

      2. This is functional, not aesthetic. A clean git history is useful.

If you follow this process, you can build anything you want and never touch the command line!

When the git Process fails

Does this process ever fail? Not theoretically, but in practice of course we’ll see things like merge conflicts (2 people changed the same level and pushed to main) or unexplainably broken projects. To prevent or deal with these things you only need 2 tools:

1. Conflict resolution skills (merge conflicts, not social)

   1. There’s a lot written about this so go look it up. I will say, conflicts should be rare if you keep to the process.

2. Delete button

   1. If all else fails, literally delete the whole project on your computer and re-download it from Github

And that’s all! A few steps to be able to create a project without ever completely destroying it.

Why am I writing this?

1. I’m writing to provide what I wish I had while learning — real thought process on design and engineering, opinions on tradeoffs, and acknowledging how often I’m wrong.

2. I believe everyone can learn anything, and the more breadth you get the more you’re able to solve problems. Depth is easy to access (still challenging to gain) today, Youtube University is available to almost everyone. I hope to convince you over time, not just with this post. If you leave here clicking only one link, learn basic design thinking. If you’re an engineer I encourage you to learn fine art. If you’re an artist, I encourage you to believe you can learn to structure logic (programming) and describe the world objectively (math), and then go for it. Find joy and beauty in all of this. If you look for it, you will find it.

If you’d like to check out more of my work, visit my website at https://sidnaik.io/

or any of my socials @SidsCreativeTech :)