1.git stash梳理
1.1git stash的克隆與同步
首先整理下git stash的邏輯是這樣
在本地做出了新的修改，提交時顯示當前的版本不是最新版本，這時就需要先pull一下自己代碼倉庫的最新版本的develop。
在git stash的setting中如果設置了自動同步，那自己的代碼倉庫與總庫的代碼倉庫則會隨時同步，這時pull自己的develop就已經會得到最新版本了
1.2服務器版本更新時的做法
在拉下來之后可以選擇是使用git rebase達到快進還是直接使用git merge
如果你不是在董鉑然博客園看到本文，請點擊查看原文
官（li）方（yu）說這里不能直接使用merge，最好先使用rebase，因為如果直接使用merge會將自己新增的功能與最新的版本合並成一個新的版本。而使用rebase是先把最新的版本拉下來，並把自己新增功能的改動編輯在最新的版本里，這樣再次提交時，我們新增的改動就是一個獨立的版本而不是與某個版本合並所產生的版本。
1.3對比日志圖得出結論
看日志圖的話效果更加直觀
近期代碼由我們維護的可以看到日志圖如下
每一個版本各自獨立，結構清晰
而往期工程師在維護時使用merge，則造成了較為模糊難以理解的日志如下
在往前看以前的MOMA項目日志更加混亂
所以往后的做法都是使用rebase進而達到fast-forward的效果的做法。
2.git squash技術
在使用git作為源代碼管理器時，需要時不時將自己所作出的改變commit，以便查詢。工作中是建議稍微做一些小的改動就commit的，因為提交的越細看着越清楚。但是當在將自己的代碼倉庫改過許多細節提交到服務器建立一個pull request時，有時需要將瑣碎的多個commit結合起來形成這一個需求的完整commit。這時就需要使用git squash來整理壓縮message。
當我修改了四個文件並且每一個步驟都是分開提交的，我的項目git log顯示如下：
如果將每一個commit都建立pr並提交到主代碼倉庫，主庫的修改版本會非常多，為今后的維護也加大了難度。如果使用git squash技術可以將多個log集結到一起。 關於具體的代碼操作可見下面完整PR操作步驟的2-7步。
3.完整PR操作步驟(12步)
1.git remote -v 先查看下起源避免出錯
2.git checkout ChangeBadCode 先切換到自己的項目分支
3.git log 查看下日志，並判斷需要將多少個日志合並
4.git rebase -i HEAD~6 把頂部的六個版本聚到一起進入編輯頁面
5.把需要壓縮的日志前面的pick都改為s（squash的縮寫）
這里要注意必須保留一個pick，如果將所有的pick都改為了s那就沒有合並的載體了就會報如下錯誤
這時就只能使用 git rebase --continue 繼續編輯或git rebase --abort 取消此次操作來解決問題才能進入下一步。
6.（前面的操作無誤的話）輸入:wq保存並退出這時出現修改message頁面
7.使用vim指令把每個message之間的空格行給刪除，並輸入:wq
最終達到的效果是這樣
8. 想獲取develop的最新版本必須先切換到develop --------git checkout develop
9. git pull origin develop 獲取最新的develop版本
10. 需要先切換到自己的分支，才能對develop進行rebase -----git checkout NewFix
11. git rebase develop 把自己新開發的功能快進最新版本
12. 這時候需要先切換到主干才能把自己的分支合並 ------git checkout develop
13. git merge NewFix 這時候才能合並
14. git push origin develop 推到自己的起源代碼倉庫
15. 在網頁上創建pull request向管理員提交變更
附加幾個常用指令（后續繼續增加）：
git branch 查看分支
git reflog 查看這個項目的修改記錄
git log --graph --oneline 顯示前六位log碼和對應的message
git checkout -b NewFix 在主分支上建立一個新的分支。
git cherry-pick ChangeBadCode 在新的分支上復制舊分支的改變
git branch -d ChangeBadCode 刪除一個分支。 -D是強制刪除
git add . 把改動全部加上。 （可以先用git status顯示出不同的diff）然后add 單個文件
git commit --amend 給剛提交的commit訂一下，但是不生成log