網易視訊雲是網易傾力打造的一款基于雲計算的分布式多媒體處理叢集和專業音視訊技術，提供穩定流暢、低延遲時間、高并發的視訊直播、錄制、存儲、轉碼及點播等音視訊的PAAS服務，線上教育、遠端醫療、娛樂秀場、線上金融等各行業及企業使用者隻需經過簡單的開發即可打造線上音視訊平台。現在，網易視訊雲的技術專家給大家分享一則技術文：記一次.gitignore的操作細節。
“作為一個剛上路的新手司機，git操作當然要遠離各種炫酷的git GUI，因為這些GUI容易使你忽略git本身的工作流程，走向萬劫不複的深淵。” ---- 一位上路多年的老司機對我說 這個事情發生的背景是這樣的，在我們的專題釋出系統工程裡面，本地開發的css檔案采用scss實時watch編譯方式，最終釋出到線上時，也會重新壓縮合并css檔案，一直以來都沒有什麼問題。但是随着開發人員的增多，代碼送出頻次的增加，以及每個人的編輯器環境不同，會導緻編譯出的css檔案有些許的不同，比如有人watch出的css檔案裡面會有charset聲明：@charset "UTF-8";這些檔案的更改都被送出上來了。這個時候當我去拉代碼時，每次都會出現不少的conflict，我必須停下來，更改scss檔案，重新watch一次，才能把我的修改送出。時間一長，工作的效率就降低了。 好了，有問題就解決呗，我考慮到scss檔案本來在代碼釋出的時候會被編譯成css檔案，也會有相應的壓縮合并等，那把css檔案和css目錄ignore不就好了嗎？開發的時候，自己watch，釋出的時候，依賴自動化工具腳本執行一系列watch更新打包操作，肯定不會有什麼問題。于是，我輕車熟路的打開了.gitignore檔案,啪啪啪，增加了css/忽略規則，commit送出。 這個時候有css檔案修改，git status 看一下， 咦，腫麼css檔案還是 Changes not staged for commit ，難道我gitignore正規表達式寫錯了？ 查了一些，好像沒問題啊。好，google一下： 原來是我誤解了 .gitignore 檔案的使用方法， .gitignore隻能作用于 Untracked Files，也就是沒有被 Git 記錄過的檔案，或者說沒有add和commit相關操作的檔案。 這裡就能解釋我的規則不生效的原因是css目錄下的檔案都存在了git操作記錄，此刻再加入到 .gitignore 就無效了。解決這個問題，我們可以這樣做：
- 删除git對于該檔案的追蹤資訊；
# -r 遞歸删除檔案夾裡内容 git rm -r --cached <path> - 更新 .gitignore，把對應的規則寫入 .gitignore
- add＋commit + push。
好了，試一下，
commit，push代碼 這時候如果有css檔案的修改，我們git status試下
奇怪了，這個怎麼回事呢，對css檔案的追蹤也删除了，gitignore也更新了，也推送到遠端分支了，可是還不對。 看一下.gitignore
發現，對于css目錄的忽略已經存在于.gitignore中了，我們的更新沒有生效。 好了，先把.gitignore中css/忽略規則删掉，送出代碼。 重新執行上面的 1->2->3 步
再次修改css檔案，好了，搞定！
PS:關于.gitignore無效還有另外一種解決方案，但是這個方案是有後遺症的，不推薦。 就是我可以設定:
git update-index --assume-unchanged <PATH>
讓git忽略我本地需要排除的檔案，送出到遠端分支後，這樣git就不會把這些修改送出到版本庫了。 那麼，這個方案有什麼問題呢？ 設定update-index這種 exclude 的方式針對的是 Git 資料庫裡被記錄的檔案，換句話說 .git/info/exclude 目錄裡是你自己本地需要排除的檔案，而不是遠端庫裡那些真正需要忽略的檔案，這樣的設定不會送出到版本庫，也不會影響他人。反觀我們的.gitignore 這個檔案本身會送出到版本庫中去。
問題就來了，如果想要達到真正忽略這些檔案的送出，必須團隊裡面每個人都去設定git update-index --assume-unchanged <PATH>才有效。 如果這個時候有新人進來或者更換電腦，從庫裡拉完最新的代碼，沒有執行git update-index --assume-unchanged <PATH>，直接送出，這時git又開始記錄該檔案的變化了。是以我們不推薦這種處理方式。 ----------------------------------------------------------------我是分割線------------------------------------------------------------- 解決了上面的問題，下面根據自己入職以來老司機對我的尊尊教誨，以及我們技術組裡面的要求，總結下git使用方面的一些奇技淫巧和好的習慣： 1.每次送出代碼前，仔細檢視更改。 代碼送出謹慎些，操作前可以使用git status、 git diff，看看有沒有誤改檔案，或者有沒有debugger、alert等調試代碼送出。根據經驗，很多時候，小手一抖，就送出了一些莫名其妙的修改，這個排查起來很費時費力。 2.pull和push最好帶上分支名。 同時push.default請修改為simple方式。當我們把git更新後，會看下如下提示：
warning: push.default is unset; its implicit value is changing in
Git from 'matching' to 'simple'. To squelch this message
and maintain the current behavior after the default changes, use:
git config --global push.default matching
To squelch this message and adopt the new behavior now, use:
git config --global push.default simple
我們可以看到，Git 2.x 預設的是 simple，而 Git 1.x 預設的是 matching，就是說在沒有指定分支的前提下，Git 2.x預設處理目前分支，Git 1.x則将所有你本地的分支push到遠端倉庫中對應比對的分支。這是一件很危險的事情，尤其當master分支出現權限控制異常時。我們這邊出現過master分支權限控制的問題，有同僚把master分支的誤操作送出上去了，後果可想而知。謹慎起見，先修改push.default，然後pull和push帶上遠端分支名。 3.配置git alias，可以節省不少git操作時間
git config --global alias.st status
# git操作頻次較高的指令大概有一下幾個：
[alias]
st = status
ci = commit
co = checkout
br = branch
4.關于git rebase 為了保證git送出樹的幹淨，避免出現眼花缭亂的merge操作記錄，建議使用git rebase進行替換。 5.優化git commit的送出日志 git commit時盡量不要隻是簡單的 update，dev，bugfix等，因為這些标記确實不利于後續的問題定位查找。我們開發小組已經硬性規定，誰再送出這樣簡單的commit标記，要請吃水果，貌似有不少同學中招了~
總之對于git工具的使用，還是需要慢慢摸索，不斷實踐的。當大家使用熟練後，再配合git GUI也是沒問題的。最後，希望這篇文章能對大家有用，各位有什麼好的git操作建議，歡迎交流~