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
  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 reset --hard
  20
  21 to go back to where you were. To save the state again:
  22
  23  $ git commit -a -m "another backup"
  24
  25 Tip: the hyphen after "git" may be replaced by a space if you prefer.
  26
  27 ==== Add, Delete, Rename ====
  28
  29 The above will only keep track of the files that were present when you first ran *git add*. If you add new files or subdirectories, you'll have to tell Git:
  30
  31  $ git add NEWFILES...
  32
  33 Similarly, if you want Git to forget about certain files, maybe because you've deleted them
  34
  35  $ git rm OLDFILES...
  36
  37 Renaming a file is the same as removing the old name and adding the new name. There's also the shortcut *git mv* which has the same syntax as the *mv* command. For example:
  38
  39  $ git mv OLDFILE NEWFILE
  40
  41 === Advanced Undo/Redo ===
  42
  43 Running:
  44
  45  $ git log
  46
  47 shows you a list of recent commits, and their SHA1 hashes. Then:
  48
  49  $ git commit -a
  50  $ git revert SHA1_HASH
  51
  52 will load the previous state with the given hash.
  53 Don't like cutting and pasting hashes? Then use:
  54
  55  $ git revert "@{10 minutes ago}" .
  56
  57 Other time specifications work too. Or you can ask for the 5th-last saved state:
  58
  59  $ git revert "@{5}" .
  60
  61 Running *git log* reveals that the fact that you loaded an old saved state has been recorded as new commit. In other words, Git tracks your undo and redo operations.
  62
  63 Sometimes you just want to go back and forget about every change past a certain point because they're all wrong. Then type:
  64
  65  $ git reset --hard SHA1_HASH
  66
  67 which restores the state to a given commit and also erases all newer commits from the record permanently.
  68
  69 Using *git checkout* is a third way to load an old state, but it's slightly more complicated because it involves branches, and will be discussed in detail later.
  70
  71 To take the computer game analogy again:
  72
  73 - *git revert* is like loading a game and recording this fact as a new saved game,
  74
  75 - *git reset --hard* is like loading an old save and deleting all saved games newer than the one just loaded, and
  76
  77 - *git checkout* is like loading an old game, but if you play on, the game state will deviate from the newer saves you made the first time around. Any saved games you make now will end up in a separate branch representing the alternate reality you have entered. We describe how to deal with this later.
  78
  79 For reset and checkout, you can choose only to restore particular files and subdirectories by appending them after the command.
  80
  81 === Dowloading Files ===
  82
  83 If a project uses Git to manage its files, you can get a copy with:
  84
  85  $ git clone git://server/path/to/files
  86
  87 For example, to get all the files I used to create this site:
  88
  89  $ git clone git://git.or.cz/gitmagic.git
  90
  91 We'll have a lot more to say about the *clone* command later.
  92
  93 === The Bleeding Edge ===
  94
  95 If a project uses Git to manage its files, and you've already downloaded a copy using *git clone*, you can upgrade to the latest version with:
  96
  97  $ git pull
  98
  99 === Instant Publishing ===
 100
 101 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 could wind up in trouble.  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.
 102
 103 To do this with Git, in the directory where your script resides:
 104
 105  $ git init
 106  $ git add .
 107  $ git commit -m "first release"
 108
 109 Then tell your users to type
 110
 111  $ git clone your.computer:/path/to/script
 112
 113 to download your script. This assumes they have ssh access. If not, run *git daemon* and tell your users to type
 114
 115  $ git clone git://your.computer/path/to/script
 116
 117 From now on, every time your script is ready for release, type:
 118
 119  $ git commit -a -m "next release"
 120
 121 and your users can upgrade their version by changing to the directory containing your script and typing.
 122
 123  $ git pull
 124
 125 Your users will never end up with a version of your script you don't want them to see. Obviously this trick works for anything, not just scripts.
 126
 127 === What Have I Done? ===
 128
 129 Find out what changes you've made since the last commit with:
 130
 131  $ git diff
 132
 133 Or since yesterday:
 134
 135  $ git diff "@{yesterday}"
 136
 137 Or between a particular version and 2 versions ago:
 138
 139  $ git diff SHA1_HASH "@{2}"