Skip to content

Commit 281f55a

Browse files
authored
Merge pull request #862 from rpjday/recording
Wording/grammar/clarification tweaks to "Recording Changes" section
2 parents 66ea7e1 + e93922f commit 281f55a

File tree

1 file changed

+9
-7
lines changed

1 file changed

+9
-7
lines changed

book/02-git-basics/sections/recording-changes.asc

Lines changed: 9 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1,15 +1,17 @@
11
=== Recording Changes to the Repository
22

3-
You have a bona fide Git repository and a checkout or working copy of the files for that project.
4-
You need to make some changes and commit snapshots of those changes into your repository each time the project reaches a state you want to record.
3+
At this point, you should have a _bona fide_ Git repository on your local machine, and a checkout or _working copy_ of all of its files in front of you.
4+
Typically, you'll want to start making changes and committing snapshots of those changes into your repository each time the project reaches a state you want to record.
55

6-
Remember that each file in your working directory can be in one of two states: tracked or untracked.
6+
Remember that each file in your working directory can be in one of two states: _tracked_ or _untracked_.
77
Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged.
8+
In short, tracked files are files that Git knows about.
9+
810
Untracked files are everything else – any files in your working directory that were not in your last snapshot and are not in your staging area.
911
When you first clone a repository, all of your files will be tracked and unmodified because Git just checked them out and you haven't edited anything.
1012

1113
As you edit files, Git sees them as modified, because you've changed them since your last commit.
12-
You stage these modified files and then commit all your staged changes, and the cycle repeats.
14+
As you work, you selectively stage these modified files and then commit all those staged changes, and the cycle repeats.
1315

1416
.The lifecycle of the status of your files.
1517
image::images/lifecycle.png[The lifecycle of the status of your files.]
@@ -213,12 +215,12 @@ $ cat .gitignore
213215
The first line tells Git to ignore any files ending in ``.o'' or ``.a'' – object and archive files that may be the product of building your code.
214216
The second line tells Git to ignore all files whose names end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files.
215217
You may also include a log, tmp, or pid directory; automatically generated documentation; and so on.
216-
Setting up a `.gitignore` file before you get going is generally a good idea so you don't accidentally commit files that you really don't want in your Git repository.
218+
Setting up a `.gitignore` file for your new repository before you get going is generally a good idea so you don't accidentally commit files that you really don't want in your Git repository.
217219

218220
The rules for the patterns you can put in the `.gitignore` file are as follows:
219221

220222
* Blank lines or lines starting with `#` are ignored.
221-
* Standard glob patterns work.
223+
* Standard glob patterns work, and will be applied recursively throughout the entire working tree.
222224
* You can start patterns with a forward slash (`/`) to avoid recursivity.
223225
* You can end patterns with a forward slash (`/`) to specify a directory.
224226
* You can negate a pattern by starting it with an exclamation point (`!`).
@@ -231,7 +233,7 @@ Here is another example `.gitignore` file:
231233

232234
[source]
233235
----
234-
# no .a files
236+
# ignore all .a files
235237
*.a
236238
237239
# but do track lib.a, even though you're ignoring .a files above

0 commit comments

Comments
 (0)