Git
Because what the world needs now is yet another git cheat sheet.
Overview
For my super simple needs where I'm working on hips 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 <s>destruction</s> improvement is followable, and ideally roll-backable in the impossible scenario that I've made a mistake.
The other super high level overview I'll mention is how git works. Unlike saving files to a central server, or tools like perforce that have one machine act as 'The One True File Structure', git means everyone runs their own local copy of the file system. To start work you make a copy from a git repro somewhere else (the master) onto your computer. As you change/add/delete files, you can have git create a checkpoint of your files as often as you want, which you can roll back to whenever you want (these checkpoints are called commits by git). But this is all local to you, the master git repro elsewhere is unaffected by your changes.
It's only when you think you've got something worth sharing, that you can choose to merge your files back with the master branch. In fact you can keep downloading changes made to the master branch to your local copy, even before sending your own changes back, git is happy to do this too. But thats the gist; make a copy of the master git repro, do all the versions and commits and stuff you want locally, and when you're done, push them back to the master.
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 repository. Well done!
If gitlab/github require you to login, the best way is to setup ssh keys. Basically make a ssh key on your machine, copy the public key part to your gitlab account, then you should be golden. More info: https://docs.gitlab.com/ee/ssh/index.html#generate-an-ssh-key-pair
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:
- Pull the latest changes from the web repro, as other people in other remote locations have done work while you slept
- Do things, make changes, break stuff
- Tell git 'yes, track these changes, ignore those changes'
- Tell git a commit comment for those changes
- Push those changes back to the web repo
- Make more changes, more commits through out the day
- After the final push for the day tell people in slack what you did
- 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 positionfixed uvs on pig in myfile.hip and added bake ropsuvs were reversed on pig, fixed with uvtexture sopadded 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
Branch
'Hey, can you swap to the experimental branch and do your work in there from now on?'
YES I CAN.
git branch -a
Will list all the available branches, likely if you're reading this all the ones available on the remote site, and few or none of the local ones. To get the remote experimental branch and copy it to a local branch called 'experimental':
git checkout -b experimental origin/experimental
Yes you need to assign a local name.
Branches are kind of like takes in houdini speak; you can try out different things in different branches, they won't affect each other until you need to, at which point you can start merging branches together back into your main commit history.
If I want to make my own branch from scratch to keep away from everyone else, just call git branch with a new name:
git branch thebestbranch
And I can see the branches available with
git branch
Now I want to swap to that branch:
git checkout thebestbranch
This is the equivalent of being in a take now. I can do stuff, commit make files, break things. If I want to go back to the master branch:
git checkout master
Oh whats that Xzibit? You tried to list the branches by going 'git branch', but instead made a branch called 'branch', and you want to delete the branch branch?
git branch -d branch
More advanced stuff
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.
Modify the latest commit message
git commit --amend
Handy if you forgot to do a complete log of the work you changed, which I do all the time.
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 extra 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 -f -d
...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.
Add all changed files
You've changed a bunch of files git already knows about in lots of different folders, you can't be bothered to 'git add' each file, git can find them all for you and add them ready to be committed. The -u stands for 'update'.
git add -u
Add all new files too
You've added a bunch of new things that git doesn't yet know about, you want git to also include those in the next commit. A period in the top level folder will go find all the as yet untracked files.
git add .
Make a local fresh git folder
So you're doing work from scratch locally, not pulling anything from github/gitlab yet, just a local safe space.
Make a folder, jump inside and run
git init
Branch workflow
Very similar to the above stuff, just summarised and generalised. Overview:
- You have a main repo, you want to make a change
- Create a new branch, swap to it
- Make your changes, commit etc
- Push your branch to the original repo
- If changes are made to the main branch while you're in your branch, pull and merge those changes into your branch
- When complete, commit and push your branch
- Swap to main, merge branch into main
- Delete the branch
Ok? Here's all that in bash/git form:
# make a branch
git checkout main # make sure you're all up to date yeah?
git checkout -b coolbranch # make branch, swap to it
# do work
# ...
# make changes
# ...
git add *
git commit -m "changes made" # commit stuff
# push your branch to the repo
git push # what you run normally, but the first time it won't work.
# it will give you the following command, run this, then git push will work the next time.
git push --set-upstream origin coolbranch # neat
# if main has changed, pull and merge into your branch:
git checkout main
git pull
git checkout coolbranch
git merge main
# all done! now merge the branch back into main, and delete the branch
# (assume you've already pulled main into your branch)
git checkout main
git merge coolbranch # merge coolbranch into main
git push
git branch --delete coolbranch # delete the local branch
git push origin --delete coolbranch # delete the branch on the main repo# make a branch
git checkout main # make sure you're all up to date yeah?
git checkout -b coolbranch # make branch, swap to it
# do work
# ...
# make changes
# ...
git add *
git commit -m "changes made" # commit stuff
# push your branch to the repo
git push # what you run normally, but the first time it won't work.
# it will give you the following command, run this, then git push will work the next time.
git push --set-upstream origin coolbranch # neat
# if main has changed, pull and merge into your branch:
git checkout main
git pull
git checkout coolbranch
git merge main
# all done! now merge the branch back into main, and delete the branch
# (assume you've already pulled main into your branch)
git checkout main
git merge coolbranch # merge coolbranch into main
git push
git branch --delete coolbranch # delete the local branch
git push origin --delete coolbranch # delete the branch on the main repo