add and status basically done
Scott Chacon committed
Jun 3, 2010 at 20:13 UTC
8ea8f0ccc7d7f7a24e797800d218f5f862dd31e9
6 files changed
+232
-9
NOTES
+6
@@ -31,3 +31,9 @@ Fixing History
31
* rebase
32
* revert
33
34
+
35
+ <div class="note">
36
+ <h3>My Note</h3>
37
+ this note is pretty cool.
38
+ this note is pretty cool.
39
+ </div>
_layouts/reference.html
+3
-3
@@ -2,7 +2,7 @@
2
<html xmlns="http://www.w3.org/1999/xhtml">
3
<head>
4
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
5
- <title>Git Quick Reference</title>
5
+ <title>Git Reference</title>
6
<link rel="stylesheet" type="text/css" href="/css/reset.css" media="screen" />
7
<link rel="stylesheet" type="text/css" href="/css/text.css" media="screen" />
8
<link rel="stylesheet" type="text/css" href="/css/grid.css" media="screen" />
@@ -18,13 +18,13 @@
18
<div class="container_12">
19
20
<div class="grid_12">
21
- <span id="branding">Git Quick Reference</span>
21
+ <span id="branding">Git Reference</span>
22
</div>
23
24
<div class="grid_12">
25
<ul id="menu">
26
<li><a id="menu_home" href="/index.html">Reference</a></li>
27
- <li><a id="menu_recepies" href="#">Recipies</a></li>
27
+ <!-- <li><a id="menu_cookbook" href="/cookbook.html">Cookbook</a></li> -->
28
<li><a id="menu_about" href="/about.html">About</a></li>
29
<li>§</li>
30
<li><a href="http://github.com/schacon/git-reference">Site Source</a></li>
basic/index.html
+188
-2
@@ -6,10 +6,196 @@ layout: reference
6
<h2>Basic Snapshotting</h2>
7
<div class="block">
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.
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
+
197
</div>
198
</div>
199
14
-<p><a href="/basic">On to Adding Content »</a></p>
200
+<p><a href="/basic">On to Branching and Merging »</a></p>
201
cookbook.html
new
+12
@@ -0,0 +1,12 @@
1
+---
2
+layout: reference
3
+---
4
+<div class="box">
5
+ <h2>Git Cookbook</h2>
6
+ <ul>
7
+ <li>Revert a file</li>
8
+ <li>Recover a lost branch</li>
9
+ <li>Contribute to a project on GitHub</li>
10
+ <li>Undo a merge</li>
11
+ </ul>
12
+</div>
css/layout.css
+18
@@ -31,12 +31,30 @@ body {
31
32
code { background: #ffe; padding: 2px 5px; }
33
34
+p.nutshell {
35
+ background: #ddd;
36
+ padding: 5px;
37
+}
38
+
39
.box pre {
40
margin-top: 10px;
41
padding: 8px;
42
background: #ffe;
43
}
44
45
+.box code.code {
46
+ white-space:pre;
47
+ font-family:monospace;
48
+ padding: 8px;
49
+ background: #ffe;
50
+ display: block;
51
+ margin: 10px;
52
+ color: #555;
53
+}
54
+code.code b { color: #111; }
55
+.red { color: #833; }
56
+.green { color: #383; }
57
+
58
.note {
59
float: right;
60
border: 10px;
index.html
+5
-4
@@ -14,10 +14,11 @@ layout: reference
14
</p>
15
<p>
16
Each section will link to the next section, so it can be used
17
- as a tutorial. Every page will also link to the more in-depth
18
- offical Git documentation to learn more about any of the commands.
19
- First, we'll start with thinking about source code management like
20
- Git does.
17
+ as a tutorial. Every page will also link to more in-depth
18
+ Git documentation such as the offical manual pages and relevant
19
+ sections in the Pro Git book, so you can learn more about any of
20
+ the commands. First, we'll start with thinking about source code
21
+ management like Git does.
22
</p>
23
</div>
24
</div>