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-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 == Dowloading Files ==
  80
  81 If a project uses Git to manage its files, you can get a copy with:
  82
  83  $ git-clone git://server/path/to/files
  84
  85 We'll have a lot more to say about the *clone* command later.
  86
  87 == Keeping Up-to-date  ==
  88
  89 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 released version with:
  90
  91  $ git-pull
  92
  93 == Instant Publishing ==
  94
  95 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.
  96
  97 To do this with Git, in the directory where your script resides:
  98
  99  $ git-init-db  # in git-1.5 just type git-init
 100  $ git-add .
 101  $ git-commit -m "first release"
 102
 103 Then tell your users to type
 104
 105  $ git-clone your.computer:/path/to/script
 106
 107 to download your script. This assumes they have ssh access. If not, run *git-daemon* and tell your users to type
 108
 109  $ git-clone git://your.computer/path/to/script
 110
 111 From now on, every time your script is ready for release, type:
 112
 113  $ git-commit -a -m "next release"
 114
 115 and your users can upgrade their version by changing to the directory containing your script and typing.
 116
 117  $ git-pull
 118
 119 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.
 120
 121 == What Have I Done? ==
 122
 123 Find out what changes you've made since the last commit with:
 124
 125  $ git-diff
 126
 127 Or since yesterday:
 128
 129  $ git-diff "@{yesterday}"
 130
 131 Or between a particular version and 2 versions ago:
 132
 133  $ git-diff SHA1_HASH "@{2}"