1、Git 快速教程及命令

流程： 取程式碼 → 每次工作前更新程式碼到最新版本 → 修改程式碼 → 提交程式碼到伺服器

1. 取程式碼及修改全域性設定

a. 設定使用者名稱與郵箱

git config –global user.name “My Name”
git config –global user.email “[email protected]”

b. 從已有的git庫中提取程式碼

git clone [email protected]:app .git myrepo

1. 每次更改程式碼的操作

a. 更新原生代碼到最新版本（需要merge才能合到原生代碼中）

git fetch

b. 合併更新後的程式碼到本地

git merge

c. 更新程式碼方式的另一種方法(git pull是git fetch和git merge命令的一個組合)

git pull

d. 修改程式碼後，檢視已修改的內容

git diff –cached

e. 將新增加檔案加入到git中

git add file1 file2 file3

f. 從Git中刪除檔案

git rm file1
git rm -r dir1

g. 提交修改

git commit -m ‘this is memo’

如果想省掉提交之前的 git add 命令，可以直接用

git commit -a -m ‘this is memo’

commit和commit -a的區別, commit -a相當於：

第一步：自動地add所有改動的程式碼，使得所有的開發程式碼都列於index file中
第二步：自動地刪除那些在index file中但不在工作樹中的檔案
第三步：執行commit命令來提交

h. 提交所有修改到遠端伺服器，這樣，其它團隊成員才能更新到這些修改

git push

1. 附註

遇到過的一些錯誤：

Git – fatal: Unable to create ‘/path/my_project/.git/index.lock’: File exists.

fatal: Unable to create ‘/path/my_proj/.git/index.lock’: File exists.

If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.
 

可以試著刪除 index.lock

rm -f ./.git/index.lock

2、Git commit 註釋格式

Git 本身並沒有硬性限制註釋的格式，不過，對於多人蔘與的專案來說， 好的註釋風格更加有利於團隊合作。 即使是自己用，也應當堅持實用好的註釋風格， 一來是對自己的工作歷史負責，二來得以養成好的註釋習慣。 雖然這裡標題說的是 Git，其他原始碼控制系統也可以參考的。

可以先看看一些著名開源專案原始碼管理系統當中的提交註釋， 其中也有用 SVN 和 Bazaar 的， Apahe 的原始碼看不到 logview，可能是使用了 CVS 檔案格式的原因：

Linux Kernel
Apache HTTPD
Mysql Server 5.6
PHP
Git

結合其他參考文章，我總結 Git 的 推薦 註釋風格如下：

第一行為對改動的簡要總結，建議長度不超過 50，用語採用命令式而非過去式。

Vim 很貼心，在預設配置下，註釋的第一行文字顏色是黃色， 超過 50 列之後就變成白色了。

第一行結尾不要英文的句號 . ，中文的就也不要 。 吧。

為啥？我給 rst2wp 提交的時候，對方也提出了這個要求 [1] [2] ， 後來查了查，大概原因是，第一行被認為是一個“標題”，也會作為郵件標題， 而標題是不需要標點的。 上面那些開源專案也都遵守了這一規則。 不過也有 例外的 。

第二行為空行。

如果配置了自動傳送郵件，那麼第一行就用來做郵件標題， 第三行開始的內容是郵件正文， 第二行是分隔線，用於區分兩者。

第三行開始，是對改動的詳細介紹，可以是多行內容，建議每行長度不超過 72。

可以包括原因、做法、效果等很多內容，一切你認為與當前改動相關的。 為何是 72 長度呢？因為 git log 輸出的時候能顯示得比較好看， 前面 4 個空格作為縮排，後面留 4 個空格機動（英文按單詞排版）。 Vim 的 gq 命令排版很方便。

一些專案還對這個部分的內容有特殊要求，比如加一些特定標籤什麼的。

建議全部英文，首字母大寫。如果一定要用中文，請儘量使用 UTF-8 編碼。

大專案中，可以用 module/submodule: 字首作為第一行的開頭， 字首首字母不必大寫。

字首的冒號後面跟一個空格比較好看。 為了控制字串長度，子模組名稱可適當縮寫，但應保持統一。

我以前喜歡在註釋第一行加上 New: Add: Fix: 這樣的字首， 看來也是沒有必要了。

Tips: 提交之前，用 git diff –check 可以檢查有無空白字元錯誤， 比如行尾留有空白什麼的。

BTW，在使用 Git 或者其他 SCM 時，還應當避免下面這些做法：

把 SCM 當做備份工具。

SCM 是專案/程式碼管理工具，備份功能只是“福利”。 隨意將未完成測試或臨時的工作結果進行提交， 不僅破壞日誌的“純潔性”，還不利於日後的瀏覽、整理、彙總等工作。 在開源專案中這麼做的話，沒人會接受這種提交。 如果確實需要備份當前工作異地繼續的話，可以採用這樣的折衷方法：

$ git commit                # 在本地進行提交
$ git format-patch -n1      # 匯出 Patch
                            # 這個 Patch 就是你的備份
$ git am Path_To_Patch_File # 如果換了工作地點，匯入 Patch
$ git reset --mixed [hash]  # 撤銷提交，保留更改，繼續工作

一個改動不一次提交完成。

“提交”的概念是具有獨立的功能、修正等作用。 小可以小到只修改一行，大可以到改動很多檔案， 但劃分的標準不變，一個提交就是解決一個問題的。

對格式的修正，不應該和其他功能修補一起提交， 這種情況應該考慮使用 git add --edit ，git add -p 也可以用用，更復雜和強大一些。

註釋不清晰。

比如只有“修正 BUG”、“改錯”、“升級”等，沒有其他內容，等於沒說。