Difference between revisions of "Git"
|Line 78:||Line 78:|
== The rest ==
== The rest ==
Revision as of 15:56, 13 September 2020
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.
Get stuff from github
Get the clone path from github/gitlab, it'll be something like firstname.lastname@example.org:projectname/your-thing.git
cd to where you want this work to live, eg ~/git/
git clone email@example.com:projectname/your-thing.git
You now have a copy of whats on the web store. 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.
Yeah yeah git nerds, we should be branching. We've done a little bit for one very specific need, but it's not of huge importance for us right now.
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.
So, I wanna do some experiments in a branch. I can make a new branch with
git branch experiment
And I can see the branches available with
Now I want to swap to that branch:
git checkout experiment
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
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 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 -d -f
...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.