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