From Hall A Wiki
Revision as of 08:59, 16 September 2014 by Rom
A Cheat Sheat for How To Use Git
I, Bob M., got this from Brad Sawatzky in response to an e-mail.
The main thing to remember about git is that it is local (ie. on your machine). Checkouts are from your local copy, and commits are to your local copy -- you get to choose when and in what way you push your changes upstream (more on this later). Since you are only committing to your local copy, you can commit incomplete and/or non-working code with impunity. Once you have a feature that is working, you can build and push the associated set of changes up to Ole. It's impossible to lock people out of a repo the way you can with cvs/svn -- git is specifically designed to remove that problem. [Re: github authentication] You always have to authenticate before pushing changes upstream. Uploading a key just means you don't have to type in your password every time you push upstream. (Note that you do not, and should not, push every change you make upstream right away.) https://help.github.com/articles/generating-ssh-keys I find git to be *way* more lightweight (in the ease of use sense) than CVS, but it does require a change in how you think about version control. I created and used 8 independent (local) git repos last week alone while I was debugging a DAQ.
Here are the commands I use 99% of the time:
1) Create your repo git init : create empty repo from scratch git add . : add everything in this directory git commit -m'initial commit' : initialize the repository -- OR -- git clone <URL> : copy a repo from elsewhere -- Useful commands: git log : see the log file (can do this anytime) 2) Work on your code inside a new branch: git branch my-working-topic : create a branch git checkout my-working-topic : change into that branch <hack away until I have something that I want to store as a 'change'> - Branches are nice because the isolate your present work from other (possibly conflicting) changes in your repo. You can move from one branch to another to work on different things, or try out different (conflicting) ways to solve a given problem. - Useful commands at this stage: git checkout foo.c : retrieve a 'fresh' copy of foo.c, replacing my borked version git stash : stores un-committed changes in your working directory - useful if you want to switch to different branch but have local modifications that you don't want to commit just yet 3) Build a 'commit' -- Repeat these as often as you want: git add -p : 'interactively' ask about what I changes I want to record as part of this commit git add <file> : just add all changes in a given file (or add a new file) - Misc commands that are useful at this stage: git status : summary of changed files git diff --cached : review the commit you've been working on with 'git add' git diff : see diff of changes made since the last commit that are *not* in commit you're working on git reset HEAD : blow away the commit you've worked on with the 'git add's. Nothing changes in your directory -- you just start at the beginning of step 3 again. I think 'git undo' is a shortcut for this. 4) Save the commit git commit : save the change set with a notation in the log git commit --interactive : gives you a chance to edit the changeset you built in (3) without having to 'git reset HEAD' and start from scratch git commit --amend : redo the last commit (can be used to edit the comment for the last commit) - you can also add updates to your files with this commit (stuff like, 'fixed a typo', that really should have been in the last commit) - technically this makes a new commit that includes your fixups and all the stuff from the first commit. The first commit is then 'hidden' to avoid clutter. 5) goto (2) and repeat until you have something that you want to send upstream git fetch : this pulls the changes to your machine, but does NOT change your working directory at all git remote update : similar to git fetch, but will fetch from multiple remote upstreams git merge : this will attempt to merge your present state with the upstream <HEAD>. You will need to resolve conflicts at this point -- OR -- git pull : basically shorthand for a 'git fetch' followed by an automatic 'git merge' 6) Merge upstream - Talk to Ole the first time you do this -- there are many ways to handle this. One method (this is the most flexible way, but you guys might be pushing to a personal branch instead of a personal repo): git push : this will transfer the changes from your local working copy up to the (upstream/github repo) you cloned from. - You can then send a 'pull request' to Ole, OR ask that he merge your branch to master. 7) goto (2) ------------- behind a firewall at JLab ? ----------------- Need to set the proxy server git config --global http.proxy http://jprox.jlab.org:8080 and this works git clone https://github.com/rwmichaels/analyzer.git on, for example, atedf3. I'm not sure if it would work everywhere, though.
Recommended quick references:
http://www-cs-students.stanford.edu/~blynn/gitmagic/ch02.html http://schacon.github.io/git/everyday.html Graphical cheatsheet: 1 page reference
A compilation of links I've found useful: https://hallcweb.jlab.org/wiki/index.php/Git_Howto