微博git使用中那些可圈可点的地方

2018-04-05

构造干净的git历史线索

一般公司git的使用方式:

  • 一个master分支、一个dev分支,多个feature分支。
  • 一个功能点或者功能模块一个feature分支,除了日常的正常的在feature分支的提交,还要注意从master中pull最新的代码到当前所在的feature分支上,以保证当前代码是在最新的代码基础之上开发的,当前feature分支开发结束后,合并到dev分支,等到下一版本的所有feature分支都提交到dev(有时候不用所有的,dev有几个feature分支测几个功能点),测试同学在dev分支上展开测试,测试过程中产生的bug,再拎出一个或者多个feature分支进行修改,直到没问题,然后将dev中的代码合并到master,上线,然后线上回归,接着改bug。

合并分支所涉及的git指令有:

1
2
3
4
5
6
7
8
9
10
11
git pull origin master //在feature分支上
git checkout dev
git pull
git merge feature
git push

//最后上线
git checkout master
git pull
git merge dev
git push

然后生成的git历史线
img

呃。。。乱!

微博工作中的使用:

  • 一个master分支,一个或者多个feature分支。
  • 无dev分支,通常情况下远程分支只有一master分支,一两个feature分支(两个都是多的),从主干master中分出feature,开发过程中随时更新master上最新的代码,不用pull命令,而是rebase,测试环境直接用feature分支,测出的问题直接向feature分支中提,测的没问题之后,最后合并到master。
  • 在把feature分支合并到master的时候,将多个commit合并成一个。
  • 每个commit的内容都要写清楚

合并分支所涉及的git指令:

1
2
3
4
5
git checkout master 
git pull
git checkout feature
git rebase master
git push —force

将多个commit合并成一个的方法:

1
2
3
4
git reset --soft xxxxxxxxxx
git add xxxx
git commit -m "xxxx"
git push -f //一定要强制推送

img

特别清晰有木有!

git mergegit rebase的区别

一句话概括:git rebase不产生“分叉”,就像在同一个分支上commit了一样,而merge会产生“分叉”

如下图:

img

git pull 等于git fetchgit merge,每次从master更新代码的时候,如果使用git pull origin master相当于每次更新就merge了一下,因而会有很多“乱线”

git 工具选择

不要SourceTree、不要Smartgit,只用phpstrom自带的。

查看异同并修改很方便

准备提交代码:
img

查看修改了什么:
img

可以选择“查看不同”、“回滚整个文件”、“编辑当前代码”等操作,现在选择查看不同
img

点击”x”可以直接回滚到原来

img

填写commit、提交等操作

img

不用来回切换工具,直接用IDE本身,会带来很多方便,IDE的可视化效果也比较好,可以清楚的看到改动的地方,并直接在IDE中修改,能够减少“忘记改动”带来的bug