Difference between revisions of "Git Cheatsheet"

From Hall A Wiki
Jump to: navigation, search
(A Cheat Sheat for How To Use Git)
 
(3 intermediate revisions by one other user not shown)
Line 1: Line 1:
 
 
== A Cheat Sheat for How To Use Git ==
 
== A Cheat Sheat for How To Use Git ==
  
Line 18: Line 17:
 
cvs/svn -- git is specifically designed to remove that problem.
 
cvs/svn -- git is specifically designed to remove that problem.
  
 +
[Re: github authentication]
 
You always have to authenticate before pushing changes upstream.
 
You always have to authenticate before pushing changes upstream.
 
Uploading a key just means you don't have to type in your password
 
Uploading a key just means you don't have to type in your password
Line 24: Line 24:
 
   https://help.github.com/articles/generating-ssh-keys
 
   https://help.github.com/articles/generating-ssh-keys
  
git is *way* more lightweight than CVS, but it does require a change in
+
I find git to be *way* more lightweight (in the ease of use sense) than CVS,
how you think about version control.  I created and used 8 independent
+
but it does require a change in how you think about version control.  I
(local) git repos last week alone while I was debugging a DAQ.
+
created and used 8 independent (local) git repos last week alone while I was
 +
debugging a DAQ.
 
</pre>
 
</pre>
  
  
<font color="red">Here are the command I use 99% of the time:</font>
+
<font color="red">Here are the commands I use 99% of the time:</font>
 
<pre>
 
<pre>
 
   1) Create your repo  
 
   1) Create your repo  
Line 47: Line 48:
 
   <hack away until I have something that I want to store as a 'change'>
 
   <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
 
   - Branches are nice because the isolate your present work from other
     (possibly conflicting) changes in your repo.  They
+
     (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:
 
   - Useful commands at this stage:
 
   git checkout foo.c  : retrieve a 'fresh' copy of foo.c, replacing my
 
   git checkout foo.c  : retrieve a 'fresh' copy of foo.c, replacing my
 
                         borked version
 
                         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'
 
   3) Build a 'commit'
 
   -- Repeat these as often as you want:
 
   -- Repeat these as often as you want:
 
   git add -p          : 'interactively' ask about what I changes I want to
 
   git add -p          : 'interactively' ask about what I changes I want to
                         reco git add <file>      : just add all changes in a given file (or add a new
+
                         record as part of this commit
                         file
+
  git add <file>      : just add all changes in a given file (or add a new
 +
                         file)
  
 
   - Misc commands that are useful at this stage:
 
   - Misc commands that are useful at this stage:
Line 76: Line 84:
 
                       you built in (3) without having to 'git reset
 
                       you built in (3) without having to 'git reset
 
                       HEAD' and start from scratch
 
                       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
 
   5) goto (2) and repeat until you have something that you want to send
Line 81: Line 98:
 
     git fetch      : this pulls the changes to your machine, but does
 
     git fetch      : this pulls the changes to your machine, but does
 
                     NOT change your working directory at all
 
                     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
 
     git merge      : this will attempt to merge your present state with
 
                     the upstream <HEAD>.  You will need to resolve
 
                     the upstream <HEAD>.  You will need to resolve
 
                     conflicts at this point
 
                     conflicts at this point
 
     -- OR --
 
     -- OR --
     git pull      : basically shorthand for a 'git pull' followed by a
+
     git pull      : basically shorthand for a 'git fetch' followed by an
                     'git merge'rd as part of this change
+
                     automatic 'git merge'
  
 
   6) Merge upstream
 
   6) Merge upstream
Line 96: Line 116:
  
 
     git push      : this will transfer the changes from your local
 
     git push      : this will transfer the changes from your local
                     working copy up to the github repo you cloned from.
+
                     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
 
       - You can then send a 'pull request' to Ole, OR ask that he merge
         your branch to master.
+
         your branch to master.
  
 
   7) goto (2)
 
   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.
 +
 +
 
</pre>
 
</pre>
  
Line 106: Line 139:
 
   http://www-cs-students.stanford.edu/~blynn/gitmagic/ch02.html
 
   http://www-cs-students.stanford.edu/~blynn/gitmagic/ch02.html
 
   http://schacon.github.io/git/everyday.html
 
   http://schacon.github.io/git/everyday.html
 +
  [http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html Graphical cheatsheet]: 1 page reference
 +
  
   A compilation of links I've found useful here:
+
   A compilation of links I've found useful:
 
   https://hallcweb.jlab.org/wiki/index.php/Git_Howto
 
   https://hallcweb.jlab.org/wiki/index.php/Git_Howto

Latest revision as of 09:59, 16 September 2014

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