Difference between revisions of "Git"

From cgwiki
 
(15 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
Because what the world needs now is yet another git cheat sheet.
 
Because what the world needs now is yet another git cheat sheet.
  
=== Overview ===
+
== 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.
+
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.
 
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.
  
=== Get stuff from github ===
+
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
 
Get the clone path from github/gitlab, it'll be something like git@gitlab.com:projectname/your-thing.git
Line 17: Line 21:
 
You now have a copy of whats on the web store. Well done!
 
You now have a copy of whats on the web store. Well done!
  
=== Usual cycle ===
+
== 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.
 
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.
Line 34: Line 38:
 
# Sleep
 
# Sleep
  
==== Git pull ====
+
=== Git pull ===
  
 
Pull will talk to the web repro and pull any changes from there into your local copy.
 
Pull will talk to the web repro and pull any changes from there into your local copy.
Line 46: Line 50:
 
  git status
 
  git status
  
==== Git add ====
+
=== 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.
 
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.
Line 52: Line 56:
 
  git add myfile.hip
 
  git add myfile.hip
  
==== Git commit ====
+
=== 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'.
 
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'.
Line 71: Line 75:
 
  # :x to save and quit
 
  # :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
+
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 ====
+
=== Git push ===
  
 
A push will send your commits back to the web repo so the world can enjoy them.
 
A push will send your commits back to the web repo so the world can enjoy them.
Line 79: Line 83:
 
  git push
 
  git push
  
=== The rest ===
+
=== 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:
 +
 
 +
git checkout -b experimental origin/experimental
 +
 
 +
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
 +
 
 +
== 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.
 
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 ====
+
=== 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
 
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
Line 91: Line 131:
 
Which will make all files git knows about go back to how they were. Sweet.
 
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?'
+
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.
 
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
+
  git clean -f -d
  
 
...will find any untracked files and directories and remove them.
 
...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

Latest revision as of 20:27, 27 June 2021

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 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 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

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:

git checkout -b experimental origin/experimental

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

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