最近两个月，负责“xxxx”小程序的相关迭代，该项目从16年开发迭代到现在，git操作十分频繁，小小总结了一下该注意的点，希望对你大大有用。
切换现有分支需注意
我们都知道使用 git checkout branch 即可去到你想去的分支，这个情况在你当前分支没有修改代码的前提是可以行得通的，但是呢，如果一旦你修改了，git 会提示你并不能切换，此时我们有两种方法：
- commit 我们的相关代码；
- stash 暂存我们的代码。
第1种方法适用于开发完一个模块，可以提交远程仓库的情况。
第2种方法适用于开发到一半不想提交的情况，但后面在重新切回来时需要 git stash apply 恢复暂存区的内容。
创建并且切换分支需注意
在开发过程中，往往有 n 多个分支，每个模块需求都有一个独立的分支，当我在 a 分支开发到一半时，此时有一个新的模块需求，那么我需要创建并且切换一个新分支 b 进行开发，此时要注意：
先 checkout 到 master，而后习惯的先 git pull 拉取 master 上最新的代码（往往会没同步到，造成后面 merge 冲突问题）再 git checkout -b branch。
有些同学会忽略以上操作，在 a 分支就创建并且切换一个新分支 b ，但此时 b 的代码是继承来自 a 分支，这往往不是我们想要的。
commit 习惯
在各个团队内，也许并没有严格要求 commit 的 message 规范，平时你可能会这样commit：git commit -m "哈哈哈"。这样就造成了一个问题，我知道你这次提交是在笑，但是我并不知道你为什么笑。
当然有些团队内部也有自定义的规范，比如 git commit -m "[fix]我这次是修改 xx bug" ，这样也是非常好的，一目了然。下面我推荐linkxiao大佬给我的一款插件 vsc-commitizen。直接看操作：
安装完这个插件后，按“ctrl+shift+p”，输入“vsc-commitizen”（下次会直接出现在窗口，如下图），
而后，选择我们这次提交的修改类型和填写相关message即可，方便快捷。
合并分支需注意
在当前分支 a 开发完后，我们需要先 checkout 到 master，git pull 后确保拉取到 master 最新的代码之后，再切回 a 分支，如果 master 有更新，则执行 git merge master 合并分支，有冲突则解决冲突，之后再提交 push ，确保后续提 MR
提交MR/PR需注意
打开xxx，在相应的项目仓库，选择Merge Request，选择你修改的分支，后面选择checkout的老板，提交你的MR即可。
