git 协同开发,需要注意的几个小点
mtonhuang opened this issue · 1 comments
git 协同开发,需要注意的几个小点
最近两个月,负责“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"
,这样也是非常好的,一目了然。下面我推荐大佬给我的一款插件 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即可。