團隊開發中，遵循乙個合理、清晰的 git 使用流程，是非常重要的。
否則，各種不清晰的分支結構，後續產品迭代或維護都會讓人很頭疼，再如果每個程式設計師都提交一堆雜亂無章的commit，後續的快速查詢定位問題只能通過閱讀**，也是很低效的。
幾乎所有的版本控制系統都以某種形式支援分支。使用分支意味著你可以把你的工作從開發主線上分離開來，以免影響開發主線。有人把 git 的分支模型稱為它的「必殺技特性」，因為基於指標的實現使其足夠輕量。
git 鼓勵在工作流程中頻繁地使用分支與合併，哪怕一天之內進行許多次，但仍要遵循一定的規範
develop 分支
feature 分支
release 分支
hotfix 分支
當有一組 feature 開發完成，首先會合併到 develop 分支，進入提測時，會建立 release 分支。如果測試過程中存在 bug 需要修復，則直接由開發者在 release 分支修復並提交。當測試完成之後，合併 release 分支到 master 和 develop 分支，此時 master 為最新**，用作上線。
以上規範不一定是必須的，一般是根據實際情況來的，總結下自己工作中的一些問題
我們都知道，git 每次提交**，都要寫 commit message(提交說明)，否則就不允許提交，這其實就是規範，但輸入的說明我們可以隨便寫，之前我也會隨便寫，被 xx 之後就，，，
$ git commit -m "hello world"如果一行不夠，可以只執行git commit，就會跳出文字編輯器，讓你寫多行。
一般來說，commit message 應該清晰明了，說明本次提交的目的。而且多人協作的時候，有問題也方便檢視提交日誌。
目前，社群有多種 commit message 的寫法規範。來自angular 規範是目前使用最廣的寫法，比較合理和系統化。如下圖：
每次提交，commit message 都包括三個部分：header，body 和 footer。
(): // 空一行// 空一行不管是哪乙個部分，任何一行都不要有太多字元。這是為了避免自動換行影響美觀。
header部分只有一行，包括三個字段：type(必填)、scope(影響範圍，選填)和subject(必填)。
type 用於說明 commit 的類別，只允許使用下面7個標識(或者用對應的 emoji 表情，在前邊再加乙個: 就會顯示了)。
scope 用於定義 type 影響的範圍，比如資料層、控制層、檢視層等等，視專案不同而不同。
subject是 commit 目的的簡短描述，不超過50個字元。
body 部分是對本次 commit 的詳細描述，可以分成多行，每行盡量不超過72個字元。
footer 部分只用於兩種情況
還有一種特殊情況，如果當前 commit 用於撤銷以前的 commit，則必須以revert:開頭，後面跟著被撤銷 commit 的 header。
revert: feat(pencil): add 'graphitewidth' optionthis reverts commit 667ecc1654a317a13331b17617d973392f415f02.最後列出一些 git 提交支援的 emoji 表情，就算是看github 或 gitlab，也很有意思，也是目前我們專案使用的方式。
git 換行問題 git 換行符問題
最近在windows下使用git,發現不時沒有修改過的檔案要提交，對比發現檔案全部修改，但找不到不一樣的地方,baidu後懷疑是換行符的問題，因為windows和linux的換行符不一樣，這個和git客戶端配置有關係，如果每個人客戶端配置不一樣同樣會出現該問題.關於不同系統的換行符問題 unix l...
git 換行問題 Git 處理換行符問題
ps 最近又換回了 linux mint，作為乙個 linux 桌面黑，有點尷尬。換行符是 nux 與 windows 系及其他系的各種不相容問題的代表之一，於是，在不同平台使用 git 時經常碰到 git status 列出一大串修改過的檔案，git diff 檢視一下其實只是換行符問題。不多扯了...
git使用規範
push之前一定要先拉取 push之前確定分支是否正確 原則上一次上線乙個feature分支 本地分支和遠端分支不要做merge feature 分支對應的 上線以後需要刪除 每天必須提交push一次 到遠端，push之前確保 沒有編譯錯誤，程式可以正常啟動 從master分支拉取 需要看看合併相應...