git in action

You can get a Git project using two main approaches. The first takes an existing project or directory and imports it into Git. The second clones an existing Git repository from another server.

有兩種方法獲取一個Git管理的工程。第一種方法是把一個現存的工程導入到Git管理的倉庫中。第二種是從服務器複製一個現存的工程。

Initializing a Repository in an Existing Directory

If you’re starting to track an existing project in Git, you need to go to the project’s directory and type:
用git init來管理一個現存的項目

git init

This creates a new subdirectory named .git that contains all of your necessary repository files - a Git repository skeleton.At this point,nothing in your project is tracked yet.(See Chapter 10 for more information about exactly what files are contained in the .git direcotry you just created.)
這樣會建立一個.git子目錄,.git包含了git倉庫所需要的所有文件。直到這時，在你的項目中還沒有任何東西被管理。
if you want to start version-controlling existing files (as opposed to an empty directory),you should probably begin tracking those files and do an initial commit. You can accomplish that with a few git add commands that specify the files you want to track, followed by a git commit:

git add *.c
git add LICENSE
git commit -m "initial project version"

We’ll go over what these commands do in just a minute. At this point,you have a Git reposigory with tracked files and an initial commit.

Recording Changes to the Repository

You have a bona fide Git repository and a checkout or working copy of the files for that project.You need to make some chages and commit snapshots of those changes into your repository each time the project reaches a state you want to recored.

Remember that each file in your working direcotry can be in one of two states:tracked or untracked. Tracked files are fiels that were in the last snapshot;they can be unmodified,or staged.Untracked files are every-thing else - any files in your working directory that were not in your last snapshot and are not in your working direcotry that were not in your last snapshot and are not in your staging area.When you first clone a repository, all of your eiles will be tracked an unmodified because you just checked them out and haven't edited anything.
As you edit files, Git sees them as modifed,because you've chaged them since your last commit.You stage these modified files and then commit all your staged chages, and the cycle repeats.

Checking the Status of Your Files

The main tool you use to determine which files are in which state is the git status command.If you run this command directly after a clone, you should see something like this:

git status
On branch master
nothing to commit, working directory clean

This means you have a clean working direcotry - in other words, there are no tracked and modified files.Git also doesn’t see any untracked files,or they would be listed here.Finally ,the command tells you which branch you’re on and informs you that it has not diverged from the same branch on the server.For now,that branch is alway “master”,which is the default ;you won’t worry about it here.Chapter 3 will go over branches and references in detail.
Let’s say you add n new file to your peoject, a simple README file .If the file didn’t exist before, and you run git status, you see your untracked file like so:

echo 'My Project' > README
git status
On branch master
Untracked files:
(use "git add <file>..."to include in what will be committed)
README
nothing added to commit but untracked files present (use "git add" to track)

You can see that your new README file is untracked ,because it’s under the “Untracked files” heading in your status output. Untracked basically means that Git sees a file you didn’t have in the previous snapshot (commit);Git won’t start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don’t accidentally begin including generated binary files or other files that you did not mean to include. You do want to start inclduing README,so let’s start tracking the file.
Git 不會自動跟蹤任何文件，除非你明確的告訴它要跟蹤那些文件。這樣你就不用擔心Git會把二進制文件或者其他一下你不想進行跟蹤的文件進行跟蹤。

Tracking New Files

In order to begin tracking a new file, you use the command git add.To begin tracking the README file ,you can run this:

git add README

If you run your status command again,you can see that your README file is now tracked and staged to be committed:

git status
On branch master
Changes to be committed:
(use "git reset HEAD  <file>...."to unstage)
new file: README

You can tell that it’s staged because it’s under the “Changes to be committed”heading. If you commit at this point, the version of the file at the time you ran git add is what will be in the historical snapshot.You may recall that when you ran git init earlier, you then ran git add (files)-that was to begin tracking files in your directory.The git add command takes a path name for either a file or a directory; if it’s a directory, the command adds all the files in that direcotry recursiverly.
文件在“Changes to be committed”下面，證明文件已經被存儲了，如果你在這個時候提交，文件的版本將會存儲在歷史快照中。你還會從新調用git add當你調用了git init，接着調用了git add（開始跟蹤目錄下的文件）;如果是目錄的話，將會遞歸的跟蹤所有文件。

Stagin Modified Files

Let’s change a file that was already tracked. If you change a previously tracked file called CONTRIBUTTING.md and then run your git status command again, you get something that looks like this:

git status
On branch master
Changes to be committed:
(use "git reset HEAD<file>.."to unstage)
new file: README
Changes not staged for commit:
(use "git add <file>..."to update what will be committed)
(use "git checkout -- <file>..." to discard chages in working directory)
modified: CONTRIBUTTING.md

The CONTRIBUTING.md file appears under a section named “Changes no staged for commit”-which means that a file that is tracked has been modified is the working directory but not yet staged. To stage it, you run the git add command. git add is a multipurpose command - you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved. It may be helpful to think of it more as “add this content to the next commit”rather than “add this file to the project”. Let’s run git add now to stage the CONTRIBUTING.md file, and then run git status again:

git add CONTRIBUTING.md
git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..."to unstage)
new file:   README
modified:   CONTRIBUTING.md

Both files are staged and will go into your next commit. At this point,suppose you remember one little change that you want to make in CONTRIBUTING.md before you commit it. You open it again and make that change, and you’re ready to commit. However, let’s run git status one more time:

vim CONTRIBUTING.md
git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..."to unstage)
new file: README
modified: CONTRIBUTING.md
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..."to discard chages in working directory)
modified: CONTRIBUTING.md

Whta the heck?Now CONTRIBUTING.md is listed as both staged and unstaged. How is that possible? It turns out that Git stages a file exactly as it is when you run the git add command. If you commit now, the version fo CONTRIBUTING.md as it was when you last ran git add command is how it will go into the commit, not the version of the file as it looks in your working directory when you run git commit .If you modify a file after you run git add, you have run git add again to stage the latest version of the file:
CONTRIBUTING.md有兩種狀態，已存儲和未存儲。這怎麼可能？當你運行git add的時候Git的確存儲了一個文件。如果你現在提交，CONTRIBUTING.md就是你最後一次運行git add的狀態會被提交，而不是你當前文件的狀態。如果你改變了一個文件，你就要在運行git add去存儲最新的文件狀態。

git add CONTRIBUTING.md
git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..."to unstage)
new file: READ
modified: CONTRIBUTING.md

While the git status output is pretty comrehensive, it’s also quite wordy.Git also has a short status flag so you can see your changes in a more compack way. If you run git status -s or git status –short you get a far more simplified output from the command:

git status -s 
 M README
MM Rakefile
A lib/git.rb
M lib/simplegit.rb
?? LICENSE.txt

New files that are’t tracked have ?? next to them, new file that hvae been added to the staging area have an A, modified files have an M and so on. There are two columns to the output -the left hand column indicates that the file is staged and the right hand column indicates that it’s modifeid. So for example in that output, the README file is modified in the working directory but not yet staged, while the lib/simplegit.rb file is modified and staged. The Rakefile was modified,staged and then modified again, so there are changes to it that are both staged and unstaged.
違背跟蹤的文件前面是??已經被存儲的文件有一個A,被改變的文件有一個M。但是M在左邊，在右邊，和兩邊都有，又不太相同。
例如：M在右邊表示，改變了，但沒有staged，在左邊，改變了，並且已經staged，兩邊都有，改變了，staged，又改變了。

Ignoring Files

Often,you’ll have a class of files that you don’t want Git to automatically add or even show you as being as being untracked. These are generally automatically generated files such as log files or files produced by your build system.In such cases,you can create a file listing patterns to match them named .gitignore. Here is an example .gitignore file:

cat .gitignore
*.[oa]
*~
The first line tells Git to ignore any file end in ".o" or ".a" - object and archive files that may be the product of building your code. The second line tells Git to ignore all fiels that end with a tilde(~),which is used by may text editors such as Emacs to mark temporary files. You may also include a log, tmp or pid directory; automatically generated documentation; and so on. 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.
The rules for the patterns you can put in the .gitignore file are as follows:

• Bland lines or lines start with # are ignored.
• Standard glob patterns work
• You can start patterns with a forward slash (/) to avodi recursivity.
• You can end patterns with a forward slash (/) to specify a directory
• You can negate a pattern by starting it with an exclamation point(!).

Glob patterns are like simplified regular expressions that shells use.An aster-isk (*) matches aero or more characters;[abc] matches any character inside the brackets (int this case a,b,or c); a question mark(?) matches a single character; and brackets enclosing characters separated by a hyphen([0-9])matches any character between them (int this case 0 through 9).You can also use two asterisks to match nested directories; a/**/z would match a/z ,a/b/z,a/b/c/z, and so on.
Here is another example .gitignore file:
# no .a files
*.a
# but do track lib.a, even though you’re ignoring .a files above !lib.a
# only ignore the TODO file in the current directory, not subdir/TODO
/TODO
# ignore all files in the build/ directory
build/
# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt
#ignore all .pdf files in the doc/ directory
doc/**/*.pdf
GitHub maintains a fairly comprehensive list of good .gitignore file examples for dozens of projects and languages at https://github.com/github/gitignore if you want a starting point for your project.


Viewing Your Staged and Unstaged Changes

If the git status command is too vague for you - you want to know exactly what you changed, not just which files were changed - you can use the git diff command . We’ll cover git diff in more detail later, but you’ll probably use it most often to answer these two questions: What have you chaged but not yet staged? And what have you staged that you are about to commit? although git status answers those questions very generally by listing the file names, git diff shows you the exact lines added and removed - the patch, as it were.
Let’s say you edit and stage the README file again and then edit the CONTRIBUTING.md file without staging it. If you run your git status command , you once again see something like this:

git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: README
Changes not staged for commit:
(use "git add <file>... " to update what will be committed)
(use "git checkout -- <file>..." to discard chages in working directory)
modified: CONTRIBUTING.md

To see what you’ve chaged but not yet staged, type git diff with no other arguments:

git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
Please include a nice description of your changes when you submit your PR;
if we have to read the whole diff to figure out why you're contributing in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your chages into comprehensive chunks if your patch is
+longer than a dozen lines.
If you are starting to work on a particular area, feel free to submit a PR that highlights your work in progress (and note in the PR title that it's)

That command compares what is in your working directory with what is in your staging ared. The result tells you the changes you’ve made that you haven’t yet staged.
If you want to see what you’ve staged that will go into your next commit, you can use git diff – staged. This command compares your staged chages to your last commit:

git diff --staged
diff --git /a README b/README
new file mode 100644
index 0000000..03902a1
--- /dev/null
++ b/README
@@ -0,0 =1 @@
+My Project

It’s important to note that git diff by iteself doesn’t show all chages mad since your last commit - only chages taht are still unstaged. This can be confusing, beacuse if you’ve staged all of your chages, git diff will give you no output,
For another example,if you stage the CONTRIBUTING.md file and then edit it, you can use git diff to see the canges in the file that are staged and the canges that are unstaged. I four environment look s like this: