basic.txt

   1 = Basic Tricks =
   2
   3 Rather than diving into a sea of Git commands, use these elementary examples to get your feet wet. Despite their simplicity, each of them are useful in real life.
   4
   5 == Saving State ==
   6
   7 When I'm about to attempt something drastic I like to save the current state, so I can go back and try again should things go awry.
   8
   9  $ git-init-db  # for git-1.5 and up you can type "git-init" instead
  10  $ git-add .
  11  $ git-commit -m "my first backup"
  12
  13 to take a snapshot of all files in the current directory.
  14
  15 The above sequence of commands should be memorized, or placed in a script, as they will be reused frequently.
  16
  17 Then if something goes wrong, run:
  18
  19  $ git-checkout HEAD .
  20
  21 to go back to where you were. To save the state again:
  22
  23  $ git-commit -a -m "another backup"
  24
  25 === Add, Delete, Rename ===
  26
  27 The above will only keep track of the files that were present when you first ran <tt>git-add</tt>. If you add new files or subdirectories, you'll have to tell Git:
  28
  29  $ git-add NEWFILES...
  30
  31 Similarly, if you want Git to forget about certain files, maybe because you've deleted them
  32
  33  $ git-rm OLDFILES...
  34
  35 Renaming a file is the same as removing the old name and adding the new name. There's also the shortcut <tt>git-mv</tt> which has the same syntax as the <tt>mv</tt> command. For example:
  36
  37  $ git-mv OLDFILE NEWFILE
  38
  39 == Advanced Undo/Redo ==
  40
  41 Running:
  42
  43  $ git-log
  44
  45 shows you a list of recent commits, and their SHA1 hashes. Then:
  46
  47  $ git-checkout SHA1_HASH .
  48
  49 will load the previous state with the given hash.
  50 Don't like cutting and pasting hashes? Then use:
  51
  52  $ git-checkout "@{10 minutes ago}" .
  53
  54 Other time specifications work too. Or you can ask for the 5th-last saved state:
  55
  56  $ git-checkout "@{5}" .
  57
  58 In some circumstances, it is preferable to type:
  59
  60  $ git-commit -a
  61  $ git-revert SHA1_HASH
  62
  63 This appears to have the same affect, but <tt>git-log</tt> reveals that the fact that you loaded an old saved state has been recorded as new commit. In other words, you can have Git track you when you undo and redo.
  64
  65 Lastly, other times you might want:
  66
  67  $ git-reset --hard SHA1_HASH
  68
  69 which restores the state to a given commit but also erases all newer commits from the record permanently.
  70
  71 To take the computer game analogy again, <tt>git-checkout</tt> is like loading a game, <tt>git-revert</tt> is like loading a game and recording this fact as a new saved game, and <tt>git-reset --hard</tt> is like loading an old save and deleting all saved games newer than the one just loaded.
  72
  73 == Dowloading Files ==
  74
  75 If a project uses Git to manage its files, you can get a copy with:
  76
  77  $ git-clone server:/path/to/files
  78
  79 We'll have a lot more to say about the <tt>clone</tt> command later.
  80
  81 == Keeping Up-to-date  ==
  82
  83 If a project uses Git to manage its files, and you've already downloaded a copy using <tt>git-clone</tt>, you can upgrade to the latest released version with:
  84
  85  $ git-pull
  86
  87 == Instant Publishing ==
  88
  89 Let's say you've written a script you'd like to share with others. You could just tell them to download from your computer, but if they do so while you're improving the script or making experimental changes, they'll get a bad version.
  90
  91 Of course, this is why release cycles exist. Code is written, and at certain points in time, when it's suitable for others, it gets released.
  92
  93 To do this with Git, in the directory where your script resides:
  94
  95  $ git-init-db  # in git-1.5 just type git-init
  96  $ git-add .
  97  $ git-commit -m "first release"
  98
  99 Then tell your users to type
 100
 101  $ git-clone your.computer:/path/to/script
 102
 103 to download your script. From now on, every time your script is ready for release, type:
 104
 105  $ git-commit -a -m "next release"
 106
 107 and your users can upgrade their version by changing to the directory containing your script and typing.
 108
 109  $ git-pull
 110
 111 Your users will never wind up with a version of your script you don't want them to see. Obviously this trick works for anything, not just scripts.
 112
 113 == What Have I Done? ==
 114
 115 Find out what changes you've made since the last commit with:
 116
 117  $ git-diff
 118
 119 Or since yesterday:
 120
 121  $ git-diff "@{yesterday}"
 122
 123 Or between a particular version and 2 versions ago:
 124
 125  $ git-diff SHA1_HASH "@{2}"