Git Cheatsheet

Git Cheatsheet

This is a cheatsheet for Windows users using the bash git terminal.

most of these commands assume that you are using the git bash terminal and are set up with SSH / auth already working

Moving around

change folders (directories in linux-speak), specify the folder usually relative to where you currently are

cd Documents/Godot

cd can be remembered mnemonically as “Change Directory,” or “CEE DEEZ nuts!”

Go up a level

cd ..

Show your current directory (mnemonically: “print working directory”)

pwd

Display what files / folders are in the current directory (“list”)

ls

I have changes that I want others to have

(and you are on your working branch)

git add ./
git commit
git push

I want to start working on my own stuff

It’s best practice to move to your own branch if you’re collaborating with a team. Do this after getting all of the changes from “upstream”

git fetch origin
git switch main
git pull
git switch -c me/new-branch

Wait what’s all that?

1. git fetch origin you’re asking gitlab for the newest stuff. If your team is keeping that up-to-date, then you’re in luck. This doesn’t change anything, but it makes sure you know what the latest stuff is
2. git switch main set your branch to main: usually you want to get your stuff into main.
3. git pull actually set your version of main to whatever is the most current version from gitlab
4. git switch -c me/new-branch create your new branch.

After you’ve done this, you’re working off of the latest “main”

I have changes that I want others to have

git add ./
git commit
git push

this adds your current changes in your working directory to a commit. this also opens up a text editor to write your commit message in. Nerds have opinions on writing commit messages, but ask your team.

Someone else has changes I want to test

(and you’re working on your own branch that you want to save)

git add ./
git commit -m "WIP"
git fetch origin
git switch other/branch

This adds your current directory to the staging area, commits a “work in progress” commit, checks out the remote (gitlab) and then gets the branch. Often, the short name of the branch can be used

Update current branch w/ changes from remote

git fetch origin
git pull

If you’re on main or an otherwise shared branch (which isn’t special by default) this asks gitlab for the newest stuff, and sets your current branch to the latest changes.

I want to get changes from my teammate and incorporate them into mine

this one is the most tricky. I suggest you first make a commit (see Someone else has changes I want to test). This assumes you have a clean working branch, and you’re not incorporating either into main - so you’re working on some experiment.

git fetch origin
git switch other/branch
git pull
git chckout me/branch
git rebase other/branch

Don’t do this with main, unless you’re running into merge conflicts. GitLab will try to fix this automatically, and will say when it cannot.

This updates from gitlab, getting any changes from all branches, checks out to the other branch, pulls those changes to your local copy, switches back to your branch, then tries to fast-forward your changes.

If you like the current state and want it to be “your” copy, then

git push

Look at the log

git log

Exit with q.

This shows all of the commits on the repo: this can show detailed information about the previous work done.

What else?

• https://ohshitgit.com/

Why?

Did I write this

Git is super useful; if you’re working in plaintext, and care about keeping versions of things, it’s one of the best and well-established ways to work with code, and code-like things.

The UX of git is often criticized, and I don’t often find content about fixing things in a way that lots of users talk about their stuff. In fact, if you look at https://git-scm.com/learn, it’s first link is “Pro Git” which is way too long for any beginner to get going with git. Most beginners just need the list of sacred commands to get started, and a good map to figure out the rest when they need to.

Git has sharp edges: but none of these commands will let you lose data.

Not use SVN?

SVN has a reputation of being slow. SVN works better for projects that also need to track binary artifacts. If you are producing a binary (i.e. a program), then make the build part of your repo and throw SVN into the garbage can. If you’re tracking assets (big pictures, videos, music), Perforce is popular for a reason (and it’s basically svn). Mercurial is also SVN but better.

the problem with these is that there’s no popular hosts. Git has GitLab, Codeburg BitBucket, and GitHub. The SVN hosts are… not as popular.

Not use Fossil?

I don’t know it.

Not use JJ?

I’m not sure jj is better than git for most things - there’s plenty of people saying it is, but I haven’t found a good example of jj being a lot better.