Because what the world needs now is yet another git cheat sheet.
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
destruction 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 email@example.com:projectname/your-thing.git
cd to where you want this work to live, eg ~/git/
git clone firstname.lastname@example.org:projectname/your-thing.git
You now have a copy of whats on the web repository. Well done!
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
Pull will talk to the web repro and pull any changes from there into your local copy.
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.
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
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.
A push will send your commits back to the web repo so the world can enjoy them.
'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:
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
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? You tried to list the branches by going 'git branch', but instead made a branch called 'branch', and you want to delete that branch? You so silly.
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.
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:
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