這里引用一下百度百科里Git的內容：
Git --- The stupid content tracker, 傻瓜內容跟蹤器。Linus Torvalds 是這樣給我們介紹 Git 的。
Git 是用於 Linux內核開發的版本控制工具。與常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本庫的方式，不必服務器端軟件支持（wingeddevil注：這得分是用什么樣的服務端，使用http協議或者git協議等不太一樣。並且在push和pull的時候和服務器端還是有交互的。），使源代碼的發布和交流極其方便。 Git 的速度很快，這對於諸如 Linux kernel 這樣的大項目來說自然很重要。 Git 最為出色的是它的合並跟蹤（merge tracing）能力。
怎樣安裝Git這里不作介紹，請自行百度，謝謝。
8、Git管理軟件
以下例子在終端操作，我們先創建一個名為“TestGit”的文件夾：
$ mkdir TestGit
進入“TestGit”文件夾並使用git init命令把這個目錄變成Git可以管理的倉庫：
$ cd TestGit/
$ git init
你會看見“Initialized empty Git repository in /Users/baijiawei/Desktop/TestGit/.git/”，提示創建的是一個空的倉庫。
在當前目錄下，創建文件“readme.txt”，內容為"one edit"，如下圖：
另外，在終端使用ls命令，可以查看當前目錄下的所有文件：
$ ls
readme.txt
使用pwd命令可以看見當前所在的目錄結構：
$ pwd
/Users/這個不能讓你們知道/Desktop/TestGit
回歸正題，使用命令git add命令把文件添加到倉庫：
$ git add readme.txt
執行完成后不會有任何提示，說明添加成功。
最后使用git commit命令提交到倉庫：
$ git commit -m "first commit"
[master (root-commit) dc09f1d] first commit 1 file changed, 1 insertion(+) create mode 100644 readme.txt
-m后面輸入的為本次提交的備注，可以是任何字符，但最好是有意義的。
執行完命令后會告訴你這次提交的結果。
我們修改一下readme.txt的內容，如下圖：
我們可以使用git status命令查看倉庫當前的狀態：
$ git status
On branch master
Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt
結果告訴我們，readme.txt被修改過了，但還沒有提交修改。
使用git diff命令，查看文件具體的修改：
$ git diff readme.txt
diff --git a/readme.txt b/readme.txt index 4f1b13a..8794b68 100644 --- a/readme.txt +++ b/readme.txt @@ -1 +1,3 @@ -one edit \ No newline at end of file +one edit + +two edit \ No newline at end of file
diff就是difference，可以從上面的命令輸出看到，我們在第三行添加了“two edit”文字。
使用add和commit命令把修改提交到Git倉庫：
$ git add readme.txt
$ git commit -m "two edit" [master 299e07a] two edit 2 files changed, 3 insertions(+), 1 deletion(-) create mode 100644 .DS_Store
我們可以使用git log命令查看提交的記錄：
$ git log
commit 299e07a39e547e1b48f3fc657daa7e6d4ecbf6f4
Author: GarveyCalvin <1147626297@qq.com> Date: Sat Jan 17 17:25:17 2015 +0800 two edit commit dc09f1df94afd30bca6726e9f0d3459e358ac560 Author: GarveyCalvin <1147626297@qq.com> Date: Sat Jan 17 17:11:31 2015 +0800 first commit
從查詢結果我們可以看見，我剛剛總共提交了2次到Git倉庫。我們還可以看見，commit后面有一串很長的數字，那是每次提交至Git版本庫都會隨機生成的一串ID（哈希算法），用作版本號，后面我們會使用到。提示：每一個版本號都是隨機且是不同
我們還可以把記錄內容顯示壓縮為一行，在后面添加參數“--pretty=oneline”：
$ git log --pretty=oneline
299e07a39e547e1b48f3fc657daa7e6d4ecbf6f4 two edit
dc09f1df94afd30bca6726e9f0d3459e358ac560 first commit
先來回憶一下，最后修改的readme.txt文件內容如下圖所示：
我們把它回退一個版本，也就是只有“one edit”內容的readme.txt文件。
使用git reset命令進行版本回退：
$ git reset --hard HEAD^
HEAD is now at dc09f1d first commit
在Git中，HEAD表示當前版本，HEAD^表示上一個版本，HEAD^^表示再上一個版本。如果要回退更多的版本，我們可以使用HEAD~n表示。你會看見reset命令后面帶着參數“--hard”，現在先不用管它用來干什么的，先用着，在后面會說到。
我們看一下回退后的readme.txt文件內容：
可以看出來，我們已經回退了一個版本。
現在使用git log命令查看一下：
$ git log
commit dc09f1df94afd30bca6726e9f0d3459e358ac560
Author: GarveyCalvin <1147626297@qq.com> Date: Sat Jan 17 17:11:31 2015 +0800 first commit
從log命令查看的結果中發現，最新的那個版本已經看不到了，那我們還能回到最新的版本嗎？
方法是有的，前面我們介紹了Git的版本號，我們就是使用它來進行回到最新的版本：
$ git reset --hard 299e07a39e54
HEAD is now at 299e07a two edit
我們一般不需要把一整串版本號寫上去，只需要打前面的幾位即可，Git會自己進行查找。但也不要只打前面1－2位，因為這樣有可能找到重復的。
我們再次查看readme.txt文件內容：
我們再使用git log來看一下提交至Git倉庫的記錄：
$ git log
commit 299e07a39e547e1b48f3fc657daa7e6d4ecbf6f4
Author: GarveyCalvin <1147626297@qq.com> Date: Sat Jan 17 17:25:17 2015 +0800 two edit commit dc09f1df94afd30bca6726e9f0d3459e358ac560 Author: GarveyCalvin <1147626297@qq.com> Date: Sat Jan 17 17:11:31 2015 +0800 first commit
那么，如果我們當初回退了版本之后，並關閉了終端。沒過一會兒，你后悔了，需要回到最新的那個版本怎么辦？幸好，在Git中是可以有后悔葯吃的，我們可以使用git reflog命令回到未來：
$ git reflog
299e07a HEAD@{0}: reset: moving to 299e07a39e54 dc09f1d HEAD@{1}: reset: moving to HEAD^ 299e07a HEAD@{2}: commit: two edit dc09f1d HEAD@{3}: commit (initial): first commit
有了版本號ID，你就可以使用回到未來了。
這里先說一下，Git有工作區和暫存區。工作區就是我們肉眼能看到的目錄，暫存區存放的是修改的記錄。我們前面的git add命令就是把文件添加到暫存區，git commit命令就是提交暫存區的所有修改：
比如我們現在把readme.txt文件稍作修改，添加多一行文字，如下圖所示：
使用git add命令把readme.txt文件添加到暫存區：
$ git add readme.txt
我們再修改readme.txt文件的內容為：
最后使用git commit命令將暫存區提交所有修改：
$ git commit -m "three edit"
[master 5308250] three edit 1 file changed, 3 insertions(+), 1 deletion(-)
使用git status命令查看一下Git倉庫的狀態：
$ git status
On branch master
Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a")
提示有文件修改了沒添加至暫存區，為什么呢？我們剛剛不是把readme.txt文件添加到暫存區了嗎？
我們先回想一下剛剛添加的步驟：
1.修改readme.txt文件
2.把readme.txt文件添加到暫存區
3.再次修改readme.txt文件
4.提交到Git倉庫
我們是把第一次修改readme.txt文件時添加到暫存區中，因此暫存區只存放了我們的第一次修改記錄，而第二次修改后我們沒及時把readme.txt文件添加到暫存區，因此提交時只會把暫存區記錄的第一次修改提交到Git倉庫。
不相信？我們可以使用git diff命令查看本地和最新版本里readme.txt文件的區別：
$ git diff readme.txt
diff --git a/readme.txt b/readme.txt index 60f01b0..f469ed7 100644 --- a/readme.txt +++ b/readme.txt @@ -2,4 +2,4 @@ one edit two edit -three \ No newline at end of file +four \ No newline at end of file
可見，第二次修改是沒有被提交到Git倉庫里的。
如果你的當前倉庫狀態沒有任何修改，那么倉庫狀態應為：
$ git status
On branch master
nothing to commit, working directory clean
我們把readme.txt文件修改為如下內容：
我們先使用git status查看一下狀態：
$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")
有一句提示是，使用git checkout -- <file>撤消對工作區的修改。
好了，我突然間不想改這個文件了，我需要復原。那么可以使用git checkout -- file撤消對工作區的修改：
$ git checkout -- readme.txt
再次打開readme.txt文件查看內容：
果然，readme.txt已經復原了。提示：git checkout -- <file>命令是把文件回到最近一次git commit或git add時的狀態。
我們再次添加一些無用的內容，並把文件添加至暫存區：
使用git status命令查看當前的狀態：
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage) modified: readme.txt
有一句提示為，使用git reset HEAD <file>可以把該文件在暫存區的修改撤消掉。
回到正題，剛改的內容我不想提交到Git倉庫，我們可以使用git reset HEAD <file>把暫存區的修改撤消，把該文件的修改全部放回到工作區中：
$ git reset HEAD readme.txt
Unstaged changes after reset:
M readme.txt
現在再使用git status命令查看當前狀態：
$ git status
On branch master
Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a")
我們先增加一個“git.txt”文件，然后把它提交上Git倉庫：
$ git add git.txt
baijiawei-de-mac:TestGit baijiawei$ git commit -m "add git.txt" [master e7a8c02] add git.txt 1 file changed, 5 insertions(+) create mode 100644 git.txt
現在，我們把“git.txt”刪除，刪除后使用git status命令查看一下狀態：
$ git status
On branch master
Changes not staged for commit: (use "git add/rm <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) deleted: git.txt no changes added to commit (use "git add" and/or "git commit -a")
git會告訴你刪除了“git.txt”文件，但還沒提交。
情況一：使用git rm命令刪除“git.txt”命令並提交：
$ git rm git.txt
rm 'git.txt' $ git commit -m "delegate git.txt" [master 8652eea] delegate git.txt 1 file changed, 5 deletions(-) delete mode 100644 git.txt
情況二：刪除錯了文件，想要復原：
$ git checkout -- git.txt
$ ls
git.txt readme.txt
很多時候我們修改錯了文件，都可以使用git checkout命令進行復原。
我們現在新建test分支，並切換至test分支：
$ git branch test
$ git checkout test Switched to branch 'test'
或：
$ git checkout -b test
Switched to a new branch 'test'
使用git checkout命令加上-b參數，表示新建並切換至分支。
使用git branch命令查看所有本地分支，相當於 git branch --list ：
$ git branch
master
* test
其中*號后面的就是當前所在分支。
這個分支可以正常使用了，我們修改一下readme.txt的內容：
然后提交：
$ git add readme.txt
$ git commit -m "add New Num" [test 6f9e769] add New Num 1 file changed, 3 insertions(+), 1 deletion(-)
我們現在切換到master分支：
$ git checkout master
Switched to branch 'master'
再看一下readme.txt文件：
剛剛新增的一行內容已經不見了，因為我們剛剛提交的是test分支，master分支是沒有提交的。
我們現在把它們合並一下：
$ git merge test
Updating c684781..6f9e769
Fast-forward readme.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
顯示快速合並，因為不存在沖突，因此直接合並就可以了，后面會說到發生沖突時的情況。
合並后我們再看一下readme.txt文件：
內容已經合並完成了。
我們現在可以把test分支刪除：
$ git branch -d test
Deleted branch test (was 6f9e769).
在git branch命令后面加上-d參數，表示刪除分支。
我們使用git branch命令查看所有分支：
$ git branch
* master
現在就只剩下master這個分支了。
往往進行合並時都不會那么順心，往往會發生沖突。
我們現在創建branchTest分支：
$ git checkout -b branchTest
Switched to a new branch 'branchTest'
修改readme.txt文件：
在branchTest分支上提交：
$ git add readme.txt
$ git commit -m "I like here" [branchTest f1dc9cb] I like here 1 file changed, 1 insertion(+), 1 deletion(-)
切換至master分支：
$ git checkout master
Switched to branch 'master'
修改readme.txt文件：
然后在master分支提交：
$ git add readme.txt
$ git commit -m "I don't like here" [master 87ef579] I don't like here 1 file changed, 1 insertion(+), 1 deletion(-)
我們嘗試一下使用git merge合並分支：
$ git merge branchTest
Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt Automatic merge failed; fix conflicts and then commit the result.
果然，Git提示我們有錯誤發生（沖突）。它自己不能完成合並，我們需要手動解決沖突。
我們也可以使用git status命令查看沖突的文件：
$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit") Unmerged paths: (use "git add <file>..." to mark resolution) both modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a")
我們查看readme.txt文件：
Git用<<<<<<<、=======、>>>>>>>表示不同分支的內容。
我們把readme.txt文件內容改成如下圖所示：
提交修改：
$ git add readme.txt
$ git commit -m "finish merge" [master 1bb3712] finish merge
我們可以使用git log命令查看分支的合並情況：
$ git log --graph
* commit 1bb37128048d172cfe928fff96f68578b7c6f933 |\ Merge: 87ef579 f1dc9cb | | Author: GarveyCalvin <1147626297@qq.com> | | Date: Sun Jan 18 23:28:12 2015 +0800 | | | | finish merge | | | * commit f1dc9cb9e2f387b35fe323b67bf6d49eeae00ea8 | | Author: GarveyCalvin <1147626297@qq.com> | | Date: Sun Jan 18 23:16:09 2015 +0800 | | | | I like here | | * | commit 87ef57980131541f82216b7359ca7beb50c65010 |/ Author: GarveyCalvin <1147626297@qq.com> | Date: Sun Jan 18 23:19:25 2015 +0800 | | I don't like here | * commit 6f9e769ac382f77001b29bd8b2d3b92054390c3e | Author: GarveyCalvin <1147626297@qq.com> | Date: Sun Jan 18 22:55:52 2015 +0800 |
使用--graph參數可以查看分支的合並圖。大家是否覺得顯示的內容太多了？你們可以嘗試在后面添加--pretty=oneline --abbrev-commit參數，添加后再查看，你會發現結果簡潔了許多。
現在我們可以刪除branchTest分支了：
$ git branch -d branchTest
Deleted branch branchTest (was f1dc9cb).
在合並分支時，如果Git能夠快速合並（Fast-forward），那么它會直接執行合並（merge）操作。但是，使用它來進行合並（merge），合並（merge）並刪除分支后，會丟失分支信息，這樣不利於我們日后查看。
因此，我們一般會禁用快速合並（Fast-forward）功能，Git會在合並（merge）時提交一個新的Commit，這樣，我們就能從歷史上看到分支的信息。
Git merge命令后加上--no-ff就是禁用快速合並（Fast-forward）功能。
我們先建立並切換到一個新分支test：
$ git checkout -b test
Switched to a new branch 'test'
修改並提交readme.txt文件：
$ git add readme.txt
$ git commit -m "hello world" [test 4a06fc6] hello world 1 file changed, 2 insertions(+)
提交完后切換回master分支：
$ git checkout master
Switched to branch 'master'
合並test分支：
$ git merge --no-ff -m "merge test" test
Merge made by the 'recursive' strategy. readme.txt | 2 ++ 1 file changed, 2 insertions(+)
--no-ff參數表示禁用快速合並（Fast-forward），因為這次是合並並提交，因此需要加上-m參數備注分支。
合並后查看日志記錄：
$ git log --graph --pretty=oneline --abbrev-commit
* 2b7a3a0 merge test now |\ | * 561f8b3 edit readme |/
通過禁用快速合並（Fast-forward），我們可以從日志里清晰看到曾經做過合並。這是快速合並所做不到的。
為了更清晰地展現兩者間的區別，我剛剛又做了一個快速合並（Fast-forward）的操作：
$ git log --graph --pretty=oneline --abbrev-commit
* 6e84f57 error * 2b7a3a0 merge test now |\ | * 561f8b3 edit readme |/
從歷史上我們可以看到，如果是直接使用快速合並（Fast-forward），我們在歷史上就只能看到分支提交的Commit，但並不知道是從test分支上合並的; 但如果使用--no-ff參數禁用快速合並（Fast-forward），那么我們就能從歷史上清晰看到是與哪個分支合並。
有時候，我們想要創建一個臨時分支，用來修復一些緊急問題或者是突如其來的任務變更，這些誰也說不准。
在你工作沒完成的時候，突然測試人員走過來跟你說，有一個很緊急的BUG需要修復。這時候你不得不拋下目前的工作去完成他指派給你的BUG，但是，你手頭上還有工作沒完成，只完成了一部分：
$ git status
On branch master
Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a")
那么，這個時候我們可以使用git stash命令，把當前工作區的內容存儲起來，日后繼續工作的時候可以把它恢復：
$ git stash
Saved working directory and index state WIP on master: 6e84f57 error
HEAD is now at 6e84f57 error $ git status On branch master nothing to commit, working directory clean
使用git status驗證工作區是否是干凈的：
$ git status
On branch master
nothing to commit, working directory clean
從結果看出工作區是干凈的。
比如現在我們要修復一個BUG，它的ID為4293－1，我們先創建並切換到新分支：
$ git checkout -b bug-4293-1
Switched to a new branch 'bug-4293-1'
假設我們已經完成了BUG修復，提交到Git：
$ git add readme.txt
$ git commit -m "fix bug" [bug-4293-1 d82ca8f] fix bug 1 file changed, 1 insertion(+), 1 deletion(-)
切換到master分支，合並bug-4293-1分支，最后刪除bug-4293-1分支：
$ git checkout master
Switched to branch 'master' $ git merge --no-ff -m "merge fix bug" bug-4293-1 Merge made by the 'recursive' strategy. readme.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) $ git branch -D bug-4293-1 Deleted branch bug-4293-1 (was d82ca8f).
那么該回到之前的工作區上工作了，我們可以使用git stash list查看存儲的工作區列表：
$ git stash list
stash@{0}: WIP on master: 6e84f57 error
使用git stash apply恢復：
$ git stash apply
Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt
現在，工作區的文件已經全部恢復了。
最后把存儲的工作區刪除掉：
$ git stash drop stash@{0}
Dropped stash@{0} (783bdbe7bc4cfff89709dd273fd7b469a9041277)
現在已經把存儲的工作區給刪除了。現在恢復和刪除是分兩步的操作，我們還可以把它們合並為一步，也就是恢復並且刪除，我們可以使用git stash pop命令。
現在使用git stash list命令已經查看不到有存儲的工作區了：
$ git stash list
這里假定你的倉庫已經鏈接上了遠程倉庫
如何把本地分支推送到遠程分支？比如現已有分支dev，我們需要把 dev 推送到遠程分支
$ git push origin dev
有時候遠程分支已存在與本地分支相同名稱的分支，但是你又想把本地的分支覆蓋遠程相同名字的分支，這時就要強制推送了
git push -f origin dev
注意：此舉影響重大，在多人協作的時候一定要注意，很容易坑了別人又坑了自己，所以盡量避免強制推送吧
那么我們想要刪除一個遠程分支呢？比如我們要刪除遠程的dev分支
$ git push origin :dev
使用git tag <name>命令打標簽：
$ git tag v1.0.0
使用git tag命令可以查看所有標簽：
$ git tag
v1.0.0
使用git tag show <name>命令可以查看標簽信息：
$ git show v1.0.0
commit 9e53375e4a84bde213aa2a8d5c77adc251ca1503
Author: GarveyCalvin <1147626297@qq.com> Date: Tue Jan 20 11:16:58 2015 +0800 formal ...
如果是已提交但忘記打標簽的情況下，可以找到當時提交的ID，然后針對ID打標簽：
$ git log --pretty=oneline
7d5e44602cd32284782ea401dd8c2481fc12ca94 add tag
9e53375e4a84bde213aa2a8d5c77adc251ca1503 formal
ce809c52cb944e679f099ddf2d07e92469a25d53 merge fix bug
d82ca8f16ee7237bdafede1cc709a2d520137c18 fix bug
6e84f5775b0df132f4a737d7281eb0900d1de878 error
2b7a3a07c991a6a5ed4a28bc863d5211336ad96e merge test now
561f8b385bd03e8294fba643289c105de6ffc3df edit readme
ec1ffe29f87da4304abf964e7629dc671c3a59b1 test
87ef57980131541f82216b7359ca7beb50c65010 I don't like here
6f9e769ac382f77001b29bd8b2d3b92054390c3e add New Num c6847813d853e7e70739a55df487407314b7ee30 three edit new 5308250b75470b5754eca360d43a03c74820d4de three edit 299e07a39e547e1b48f3fc657daa7e6d4ecbf6f4 two edit dc09f1df94afd30bca6726e9f0d3459e358ac560 first commit
比如在merge test now提交的那一次打標簽，對應的ID是“2b7a3a07c”：
$ git tag v0.1.0 2b7a3a07c
使用git tag看一下當前所有的標簽：
$ git tag
v0.1.0 v1.0.0
可以看到我們剛剛新打的標簽v0.1.0。
再查詢v0.0.1標簽的信息：
$ git show v0.1.0
commit 2b7a3a07c991a6a5ed4a28bc863d5211336ad96e
Merge: ec1ffe2 561f8b3
Author: GarveyCalvin <1147626297@qq.com> Date: Mon Jan 19 10:21:26 2015 +0800 merge test now
可以看到，標簽已經打在了merge test now這次提交上。
我們還可以創建有說明的標簽，用-a表示標簽名稱，-m表示說明文字：
$ git tag -a v2.0.0 -m "formal v2.0.0"
查看標簽的信息：
$ git show v2.0.0
tag v2.0.0 Tagger: GarveyCalvin <1147626297@qq.com> Date: Tue Jan 20 11:38:10 2015 +0800 formal v2.0.0 commit d5161f9ba613100455a010a3afc312d32a99b68b Author: GarveyCalvin <1147626297@qq.com> Date: Tue Jan 20 11:37:28 2015 +0800 detail tag ...
可以看到我們剛剛寫的說明“formal v2.0.0”。
使用git tag -d命令刪除標簽：
$ git tag -d v1.0.0
Deleted tag 'v1.0.0' (was 9e53375)
使用git push origin <tagName>推送至遠程倉庫：
$ git push origin v1.0.0
Total 0 (delta 0), reused 0 (delta 0) To https://git.oschina.net/GarveyCalvin/testProject.git * [new tag] v1.0.0 -> v1.0.0
使用git push origin --tags把所有未推送的標簽推送到遠程倉庫：
$ git push origin --tags
Total 0 (delta 0), reused 0 (delta 0) To https://git.oschina.net/GarveyCalvin/testProject.git * [new tag] v0.0.1 -> v0.0.1 * [new tag] v0.1.0 -> v0.1.0
如果已經推送到遠程倉庫，現在想要刪除的話，首先從本地移除對應的tag：
$ git tag -d v0.0.1
Deleted tag 'v0.0.1' (was bc2cb64)
然后在git puh origin命令后面加上:refs/tags/<tag name>刪除：
$ git push origin :refs/tags/v0.0.1
To https://git.oschina.net/GarveyCalvin/testProject.git
- [deleted] v0.0.1
除了這種方法，你也可以自行到遠程倉庫網站把Tag刪除。
在有些時候，我們的Git項目里會有一些特殊的文件，可能是系統自生成的文件，在你每次提交的時候都會提示你有文件改動了，提示你添加這些文件。這樣是不是很煩人？因此我們需要忽略這類文件。
比如在Mac系統里，每個文件夾都會生成一個".DS_Store"的隱藏文件，用來存放文件夾的排序等信息，這些文件也會在查看git status時出現，並且它們出現的次數非常多，令人感覺非常煩。你是否有疑惑為什么你看了這篇博文這么久，都沒有看到過這些提示，那是因為我沒截全部的提示：）。好了，下面就教大家怎樣去忽略它。
我們需要在Git工作區的根目錄下創建.gitignore文件，在這之前我們先創建一些需要忽略的文件夾：
以上這些文件和文件夾都是需要Git去忽略掉的。
我們先使用git status查看一下狀態：
$ git status
On branch master
Your branch is up-to-date with 'origin/master'. Untracked files: (use "git add <file>..." to include in what will be committed) .DS_Store bad/ ignore/ other/ nothing added to commit but untracked files present (use "git add" to track)
沒自定義忽略的文件/文件夾前，會把所有改動過的文件/文件夾進行提示。
如果你們沒看見有文件夾顯示，那是因為你的文件夾下沒有文件/文件夾，Git自動會忽略空目錄。解決方法很簡單，只要在文件夾下添加文件就可以了。
現在我們可以創建.gitignore文件了，文件內容如下所示：
# remark
*.DS_Store ignore
other
bad
有#號的那一行都是備注，並沒有實質作用。
*.忽略后綴名為……的文件
ignore、other、bad為忽略的文件夾
注意，要把.gitignore文件放到版本庫里：
$ git add .gitignore
現在我們再使用git status查看一下狀態：
$ git status
On branch master
Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: .gitignore
現在就只能查詢到.gitignore文件了，其它需要忽略的文件/文件夾已經被忽略掉。
我們可以像開發那樣，自己定義一個關鍵字類型。
我們查看狀態時，一般都是使用git status，如果你想簡化成git st，那么：
$ git config --global alias.st status
--global參數表示全局定義，也就是說定義了之后，在當前電腦下的所有Git倉庫都通用。如果不想定義為全局，那么把--global參數去掉即可。
以后就可以直接使用git st命令查看狀態了：
$ git st
On branch master
Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: .gitignore
前面我們想要簡化git log顯示內容時，是否需要輸入一大串字符(git log --pretty=oneline --abbrev-commit)？現在我們可以為它創建別名進行簡化輸入了，並且顯示更加強大：
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
代碼片段轉自：http://blog.csdn.net/n289950578/article/details/24465663
效果如下：
全局的Git配置文件在用戶主目錄（Macintosh HD ▸ Users ▸ 你的用戶名）下的隱藏文件.gitconfig中：
當我們想要取消別名時，只需要把對應的別名行刪除即可。如果是定義非全局的Git配置文件，那么它在當前項目的根目錄下的.git隱藏文件夾下的config文件。
8、Git管理軟件
建立大家使用SourceTree管理Git庫，功能強大，界面友好，使用簡單，這里就不多作介紹了。
博文作者：GarveyCalvin
博文出處：http://www.cnblogs.com/GarveyCalvin/
本文版權歸作者和博客園共有，歡迎轉載，但須保留此段聲明，並給出原文鏈接，謝謝合作！