①Git工作流：在項目開發過程中，使用Git的方式。
一、集中式工作流（類似svn），用的相對較少，git很多特性並沒有用到。
二、GitFlow工作流。充分利用了分支的特點，實際開發中這種模式用的最多。
我們開發很多功能，需要用到分支。我們去修復bug用分支。產品正式上線之前，預發佈的時候也要用到分支。
三、Forking工作流。主要針對團隊外的成員，貢獻代碼的流程。
②GitFlow工作流詳解：
分支種類：
GitFlow工作流：
當出現bug，如果整個項目做到了高內聚，低耦合，則結構會非常清晰，bug也比較容易修復。
③分支實戰說明。
可以看出分支的創建（由程序員A操作），然後審查代碼去合併分支（由項目經理或者有經驗的架構師或者程序員操作）全部是在本地做的，而不在遠程做。輕易不要去動Master主幹分支。
④分支實戰操作。
從上圖看出，已經切換到了hot_fix
這個大於號說明，該內容已經提交給本地庫至少一次，但是在工作區又作出了更改，需要添加給（拖拽到）暫存區。
然後將修改推送到遠程。
分支圖上顯示加號，不顯示禁止符號，則表示成功。
假設TestGit02是項目經理所在的本地倉庫工程。
要進行一個拉取的操作。
等待進度條完成後，可以切換分支。此時hot_fix分支還不在本地。只在遠程。
選擇check out as 新的本地分支
檢出遠程的新分支，再點Finish
等待進度條完成。
發現TestGit02也切換到了，hot_fix分支。
如果項目經理髮現有代碼內容需要更改，則程序員A重新更改，重新push，項目經理再重新pull。但都是在hot_fix分支上進行的。
這個過程是不斷迭代進行的。
然後就是項目經理在本地合併分支。
如果要將hot_fix分支合併到master分支上面，那麼就得先切換到master分支上面：
看上圖發現已切換成master主幹。
然後合併分支：
從下圖看：選擇一個要合併的分支，是選擇遠程的，還是本地的。我們已經拉取了，所以選擇本地的hot_fix分支。
合併結果如上圖。
解決衝突。
解決衝突以後將master主幹推送到遠程倉庫。有大於號或者其他，需要先commit，然後推送。這就是常規操作。
⑤eclipse中利用git向上向下回滾各個版本。
黃色的點，和線，表示衝突發生了。
清除密碼：
