Git

Because what the world needs now is yet another git cheat sheet.

Overview

For my super simple needs where I'm working a hip and some related files with other remote artists, I need to get the files i need from github, make changes, send those changes back to github.

Bonus points for doing lots of tiny changes, and making clear comments with each update I do so my trail of destruction improvement is followable, and ideally roll-backable in the impossible scenario that I've made a mistake.

Get stuff from github

Get the clone path from github/gitlab, it'll be something like git@gitlab.com:projectname/your-thing.git

cd to where you want this work to live, eg ~/git/

git clone git@gitlab.com:projectname/your-thing.git

You now have a copy of whats on the web store. Well done!

Usual cycle

Cos I always forget, git workflow is that you're the master of your own little domain, unlike say perforce where there is only one true central repository and everyone talks directly to it.

As such the idea is now that I have my own local clone, I do all kinds of commits and updates and panics locally, I'm running my own version control. When I feel its good to share, I can push that back to the web repository.

The specific workflow for a day is usually this:

1. Pull the latest changes from the web repro, as other people in other remote locations have done work while you slept
2. Do things, make changes, break stuff
3. Tell git 'yes, track these changes, ignore those changes'
4. Tell git a commit comment for those changes
5. Push those changes back to the web repo
6. Make more changes, more commits through out the day
7. After the final push for the day tell people in slack what you did
8. Sleep

Git pull

Pull will talk to the web repro and pull any changes from there into your local copy.

git pull

Git status

Handy command to run at any time to see what git thinks you're up to. If you haven't made any changes it'll tell you. If you've made changes that git isn't aware of it'll tell you, if you're ready to push changes back to the web it'll tell you.

git status

Git add

When you make changes to a file and run git status, you'll be told 'oh, you've made a change. Do you want me to track this change?' To do this you add it to the files git will track, you collect as much as you need until you're ready to bundle all those changes as a single commit.

git add myfile.hip

Git commit

Time to tell git to record the changes you made as a commit, like a milestone, a waypoint, a place to say 'here's a bundle of work I did'.

git commit -a

Thats the goodie goodie way. It takes you to vim (woo), shows you text of what you're about to bundle together into a commit. You move to the bottom and add some text to explain what you did to yourself and others.

The usual format is a short one line summary. To be a nerd you can then have more descriptive text beneath it. Eg:

git commit -a
# vim fires up
# ]] to jump to the end of the file
# a to start Adding words After the current position
fixed uvs on pig in myfile.hip and added bake rops
uvs were reversed on pig, fixed with uvtexture sop
added rops for baking highres to lowres, single frame only, needs improving
# :x to save and quit

You'll be returned to your bash prompt, a git status will tell you you're all committed and ready for the next step

Git push

A push will send your commits back to the web repo so the world can enjoy them.

git push

The rest

What I've shown so far is 95% of what I do. The fun comes from the 5% when things go wrong, but luckily things haven't been too bad so far.

Revert via reset and clean

When you've made a series of horrible mistakes, and you just want to get stuff back to how it was the last time you pulled from the web repo. The brute force way is

git reset --hard

Which will make all files git knows about go back to how they were. Sweet.

But if you've made a bunch of files, say renders and geo output and stuff, a git status will still say 'look at all these new files that I haven't tracked yet? What do you wanna do?'

Ideally you'll just go and manually delete these yourself so you have a good mental image of whats going on, but you can have git do this for you.

git clean -d -f

...will find any untracked files and directories and remove them.

Ignore files

If you're rendering stuff a lot, it can get boring to keep telling git to not include folders full of images. You can set this permanently with a .gitignore file.

Make a .gitignore file with vim, and just put on each line the name of files or folders you want git to ignore. Eg for my project I don't want to push my $HIP/renders folder back to github, nor do I want it to see the .DS_Store files OSX leaves everywhere, so my .gitignore file looks like this:

renders
.DS_Store

Now when I make renders and run a git status, those files don't show up, so they won't be tracked, so they won't be pushed to github. Perfect.

But as an interesting aside I probably DO want to have this .gitignore file tracked by git itself, and pushed to github, so make sure to add and commit that too.