Git使用感悟

前言

分支介绍

我们现在开发的分支一般是这样的(基于上面那张图片的)：
master：上线用的
dev：开发用的
featature_xxx：开发用的
test：测试用的
hotfix：修复bug的

一般是这样子的：

公共分支：
master、dev、test，一般是不会这些分支上开发的，都是由别的分支合并到这些分支上

私有分支：
feature_xxx，hotfix_xxx，这些分支一般是由某个人或某几个人一起开发一个功能点

feature_xxx从dev分支分出来
feature_xxx合并到test去测试
feature_xxx合并到devdev合并到master
master打tag上线

hotfix分支从master分支分出来
hotfix分支合并到test去测试
hotfix分支合并到master
master打tag上线
hotfix分支合并到dev

常用指令

git branch 查看当前的分支
git checkout xxx 切换到xxx分支
git checkout -b xxx 基于当前分支创建分支xxx，并切换到xxx分支
git status 查看文件处于什么状态
git add xxx 放到暂存区，等待被commit
git commit -m "xxx" commit操作，等待被push
git push 将本地分支推向远程分支
git pull 远程分支同步到本地分支
git merge xxx 将xxx分支合并到当前分支
git log --oneline --graph 查看提交历史记录

关于 git merge

1. 第一种情况

feature_a是从dev分支分出来的，如果将feature_a合并到dev分支中，并且dev分支没有任何更改的情况下，使用merge命令的话，dev的头指针只是移动了一下，如下图所示

2. 第二种情况

如果dev分支做了改动的话，那么会新建一个commit的点，如下图所示

git merge 指令会根据不同的情况自动执行
git merge --no-ff 会强行采用第二种方案，也就是总会新建一个commit点

关于 git rebase

rebase也是合并操作，与merge不同的是，rebase 命令将另一分支上的所有修改都移至当前分支上

下面是分支情况，我们现在要把dev分支合并到feature_a上

如果采用merge的话，会产生下图效果

如果采用rebase的话，会产生下图效果，它把dev修改的commit都移动到feature_a的前面了

关于git pull

git pull 的操作是git fetch & git merge
git pull --rebase 的 操作是 git fetch & git rebase

最佳实践

git merge --no-ff：私有分支往公共分支合并的时候，比如feature_xxx往dev或test上合并的时候，产生新的commit，代表着有合并的记录
git rebase：feature_xxx需要和dev同步时，合并dev的时候，因为feature_xxx最终会合并到dev，如果采用merge的话，会有好多新的commit
git pull --rebase：使用这个命令进行git pull，不会产生新的commit

思考

不确定：当两个feature_xxx合并的时候，应该用git merge还是git rebase呢？小伙伴有什么想法可以留言一下哈

参考

git book
记一次常规的gitflow工作流 - frank
Git-Rebase-黄金法则问题 - frank