|
6 | 6 | <h2>Basic Snapshotting</h2>
|
7 | 7 | <div class="block">
|
8 | 8 | <p>
|
9 |
| - something |
| 9 | + Git is all about composing and saving snapshots of your project and then |
| 10 | + working with and comparing those snapshots. This section will explain |
| 11 | + the commands needed to compose and commit snapshots of your project. |
10 | 12 | </p>
|
| 13 | + |
| 14 | + <p> |
| 15 | + An important concept here is that Git has an 'index', which acts as sort |
| 16 | + of a staging area for your snapshot. This allows you to build up a series |
| 17 | + of well composed snapshots from changed files in your working directory, |
| 18 | + rather than having to commit all of the file changes at once. |
| 19 | + </p> |
| 20 | + |
| 21 | + <p class="nutshell"> |
| 22 | + <strong>In a nutshell</strong>, you will use <code>git add</code> to start tracking new |
| 23 | + files and also to stage changes to already tracked files, then |
| 24 | + <code>git status</code> and <code>git diff</code> to see what has been |
| 25 | + modified and staged and finally <code>git commit</code> to record your |
| 26 | + snapshot into your history. This will be the basic workflow that you use |
| 27 | + most of the time. |
| 28 | + </p> |
| 29 | + |
| 30 | + </div> |
| 31 | +</div> |
| 32 | + |
| 33 | +<div class="box"> |
| 34 | + <h2> |
| 35 | + <span class="docs"> |
| 36 | + <a href="#">docs</a> |
| 37 | + <a href="#">book</a> |
| 38 | + </span> |
| 39 | + <a name="add">git add</a> |
| 40 | + <span class="desc">adds file contents to the staging area</span> |
| 41 | + </h2> |
| 42 | + |
| 43 | + <div class="block"> |
| 44 | + <p> |
| 45 | + In Git, you have to add file contents to your staging area before you |
| 46 | + can commit them. If the file is new, you can run <code>git add</code> |
| 47 | + to initially add the file to your staging area, but even if the file |
| 48 | + is already "tracked" - ie, it was in your last commit - you still need |
| 49 | + to call <code>git add</code> to add new modifications to your staging |
| 50 | + area. Let's see a few examples of this. |
| 51 | + </p> |
| 52 | + |
| 53 | + <p>Going back to our Hello World example, once we've initiated the project, |
| 54 | + we would now start adding our files to it and we would do that with |
| 55 | + <code>git add</code>. We can use <code>git status</code> to see what the |
| 56 | + state of our project is. |
| 57 | + </p> |
| 58 | + |
| 59 | +<pre> |
| 60 | +$ git status -s |
| 61 | +?? README |
| 62 | +?? hello.rb |
| 63 | +</pre> |
| 64 | + |
| 65 | + So right now we have two untracked files. We can now add them. |
| 66 | + |
| 67 | +<pre> |
| 68 | +$ git add README hello.rb |
| 69 | +</pre> |
| 70 | + |
| 71 | + Now if we run <code>git status</code> again, we'll see that they've been |
| 72 | + added. |
| 73 | + |
| 74 | +<pre> |
| 75 | +$ git status -s |
| 76 | +A README |
| 77 | +A hello.rb |
| 78 | +</pre> |
| 79 | + |
| 80 | + <p>OK, so now if we edit one of these files and run <code>git status</code> |
| 81 | + again, we will see something odd.</p> |
| 82 | +<pre> |
| 83 | +$ vim README |
| 84 | +$ git status -s |
| 85 | +AM README |
| 86 | +A hello.rb |
| 87 | +</pre> |
| 88 | + |
| 89 | + <p>The 'AM' status means that the file has been modified on disk since we |
| 90 | + last added it. This means that if we commit our snapshot right now, we will |
| 91 | + be recording the version of the file when we last ran <code>git add</code>, |
| 92 | + not the version that is on our disk. Git does not assume that what the file |
| 93 | + looks like on disk is neccesarily what you want to snapshot - you have to |
| 94 | + tell Git with the <code>git add</code> command. |
| 95 | + </p> |
| 96 | + |
| 97 | + <p class="nutshell"> |
| 98 | + <strong>In a nutshell</strong>, |
| 99 | + you run <code>git add</code> on a file when you want to |
| 100 | + include whatever changes you've made to it in your next commit snapshot. |
| 101 | + Anything you've changed that is not added will not be included - this means |
| 102 | + you can craft your snapshots with a bit more precision than most other SCM |
| 103 | + systems.</p> |
| 104 | + |
| 105 | + <p>For a very interesting example of using this flexibility to stage only |
| 106 | + parts of modified files at a time, see the '-p' option to |
| 107 | + <code>git add</code> in the Pro Git book.</p> |
| 108 | + |
| 109 | + |
| 110 | + </div> |
| 111 | + |
| 112 | +</div> |
| 113 | + |
| 114 | +<div class="box"> |
| 115 | + <h2> |
| 116 | + <span class="docs"> |
| 117 | + <a href="#">docs</a> |
| 118 | + <a href="#">book</a> |
| 119 | + </span> |
| 120 | + <a name="status">git status</a> |
| 121 | + <span class="desc">view the status of your files in the working directory and staging area</span> |
| 122 | + </h2> |
| 123 | + |
| 124 | + <div class="block"> |
| 125 | + <p>As you saw in the <code>git add</code> section, in order to see what the |
| 126 | + status of your staging area is compared to the code in your working |
| 127 | + directory, you can run the <code>git status</code> command. I demonstrated |
| 128 | + using it with the <code>-s</code> option, which gives you short output. |
| 129 | + Without that flag, the <code>git status</code> command will give you more |
| 130 | + context and hints. Here is the same status output with and without the |
| 131 | + <code>-s</code>. The short output looks like this: |
| 132 | + </p> |
| 133 | + |
| 134 | +<pre> |
| 135 | +<b>$ git status -s</b> |
| 136 | +<span class="green">A</span><span class="red">M</span> README |
| 137 | +<span class="green">A</span> hello.rb |
| 138 | +</pre> |
| 139 | + |
| 140 | + Where the same status with the long output looks like this: |
| 141 | + |
| 142 | +<pre> |
| 143 | +<b>$ git status</b> |
| 144 | +# On branch master |
| 145 | +# |
| 146 | +# Initial commit |
| 147 | +# |
| 148 | +# Changes to be committed: |
| 149 | +# (use "git rm --cached <file>..." to unstage) |
| 150 | +# |
| 151 | +# <span class="green">new file: README</span> |
| 152 | +# <span class="green">new file: hello.rb</span> |
| 153 | +# |
| 154 | +# Changed but not updated: |
| 155 | +# (use "git add <file>..." to update what will be committed) |
| 156 | +# (use "git checkout -- <file>..." to discard changes in working directory) |
| 157 | +# |
| 158 | +# <span class="red">modified: README</span> |
| 159 | +# |
| 160 | +</pre> |
| 161 | + |
| 162 | + <p>You can easily see how much more compact the short output is, but the |
| 163 | + long output has useful tips and hints as to what commands you may want to |
| 164 | + use next. |
| 165 | + </p> |
| 166 | + |
| 167 | + <p>Git will also tell you about files that were deleted since your last |
| 168 | + commit or files that were modified or staged since your last commit.</p> |
| 169 | + |
| 170 | +<pre> |
| 171 | +<b>$ git status -s</b> |
| 172 | +<span class="green">M</span> README |
| 173 | + <span class="red">D</span> hello.rb |
| 174 | +</pre> |
| 175 | + |
| 176 | + You can see there are two columns in the short status output. The first |
| 177 | + column is for the staging area, the second is for the working directory. |
| 178 | + So for example, if you have the README file staged and then you modify |
| 179 | + it again without running <code>git add</code> a second time, you'll see |
| 180 | + this: |
| 181 | + |
| 182 | +<pre> |
| 183 | +<b>$ git status -s</b> |
| 184 | +<span class="green">M</span><span class="red">M</span> README |
| 185 | + <span class="red">D</span> hello.rb |
| 186 | +</pre> |
| 187 | + <p class="nutshell"> |
| 188 | + <strong>In a nutshell</strong>, |
| 189 | + you run <code>git status</code> to see if anything has been modified |
| 190 | + and/or staged since your last commit so you can decide if you want to |
| 191 | + commit a new snapshot and what will be recorded in it. |
| 192 | + </p> |
| 193 | + |
| 194 | + |
| 195 | + </p> |
| 196 | + |
11 | 197 | </div>
|
12 | 198 | </div>
|
13 | 199 |
|
14 |
| -<p><a href="/basic">On to Adding Content »</a></p> |
| 200 | +<p><a href="/basic">On to Branching and Merging »</a></p> |
15 | 201 |
|
0 commit comments