微博git使用中那些可圈可点的地方 [ 菜刚RyuGou的博客 ]

构造干净的git历史线索

一般公司git的使用方式：

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

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

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历史线

呃。。。乱！

微博工作中的使用：

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

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

git checkout master 
git pull
git checkout feature
git rebase master
git push —force

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

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

特别清晰有木有！

`git merge`和 `git rebase`的区别

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

如下图：

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

git 工具选择

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

查看异同并修改很方便

准备提交代码:

查看修改了什么：

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

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

填写commit、提交等操作