git开发流程

在开发中，正确使用 git 能让开发事半功倍，下面我简单介绍一下在开发中的一些常见 git 操作。

分支功能介绍
我们在项目开发中，会用到如下几个不同分支。

分支	介绍
dev	内网编译分支
test	test 环境编译分支
release	待发布分支，也可以看做是外网分支
feature	需求功能分支
bugfix	bug 分支，用于修复外网 bug

不同的分支在不同的应用场景中扮演着重要的角色，所以，选择正确的分支进行开发至关重要。介绍分支显然不能脱离它的应用场景，那么，先了解一下我们开发时常见的场景有哪些。

开发中，常见的有主要有如下几个场景

内网开发新功能
修复未发布到外网的 bug
修复已发布到外网的 bug

内网开发新功能

1. 在功能分支上开发新功能

按照我们现在的开发流程，新功能肯定会对应一个禅道号，我们依据于禅道上的需求进行开发。

假如，我们有一个需求号为1650，这时候需要创建一个功能分支feature/#1650。问题来了，该从哪一个分支去创建？

由于新功能开发不能夹带没有升级到外网的代码，我们需要保证开发的分支是干净的。所谓干净的分支，就是说分支的代码要和外网的代码保持一致，而release分支正好对应的是外网的代码，所以，开发新需求，我们需要从release分支去创建功能分支。

为了保证 release 分支最新的 commit 记录，先 fetch 一下。

git fetch origin release

然后，以远程release为基准创建功能分支。

git checkout -b feature/#1650 origin/release

在开发中，我们可以在feature/#1650分支上提交很多个 commit 记录，到达一个开发阶段之后，比如需要给产品测试，我们需要把代码提交到内网 dev 环境，由于dev分支对应的是 dev 环境，所以，我们需要把功能分支上的提交合并到dev分支上。

首先切换到dev分支。

git checkout dev

我们选择rebase方式合并代码，为了不破坏原始的提交记录，让记录保持线性。

git pull origin dev --rebase

之后执行合并操作。

git merge "feature/#1650" --no-ff -m "merge: 合并#1650需求 (story#1650)"

如果出现冲突，解决冲突，解决完冲突继续合并。

git merge --continue

合并结束后，将最终代码push到远程dev分支。

git push origin dev

你可以把feature/#1650分支推送到远端，也可以选择不推送。如果推送的话，要记得在release发布之后将功能分支及时删除，防止无用远程分支过多。

2. 在内网 dev 分支上开发新功能

请记住，避免在 dev 分支直接开发新功能。如果你忘记创建功能分支，不小心在 dev 分支上提交了新需求的代码，可以按照如下步骤去操作。

第一种情况，还没有 commit

可以先执行git stash，将代码先暂存起来，然后切换到功能分支，执行git stash pop将暂存的代码释放出来。然后在功能分支开发即可。

第二种情况，已经在 dev 分支上 commit 过

首先，把 dev 分支上该需求的提交过滤出来，复制所有关于该需求提交的 hash 值，注意多个哈希值是按时间的正序排列，即最早提交的 hash 在前，后提交的 hash 在后。如果你用的是 Webstorm，它会自动帮你排好哈希顺序。

紧接着，切换到功能分支，执行 cherry-pick，将刚才选中的提交 hash 全部 cherry-pick 到功能分支上。

git checkout feature/xxx
git cherry-pick -x hash1 hash2 ...

如果出现冲突，请解决冲突，解决完执行 git cherry-pick --continue 继续，直到结束。

之后，开发在功能分支上即可。剩下的操作，和上述“在功能分支上开发新功能”一致，不再赘述。

修复未发布到外网的 bug

每一个 bug 肯定对应一个禅道 bug 编号，而禅道上的 bug 肯定是经过产品或测试的同事测出来提的 bug，所以代码肯定是已经发布到 test 环境中了。那么，我们修改 bug，可以在本地的test分支中直接修改，改完直接push到远程的test分支。

首先，切换到test分支。

git checkout test

然后在test上修改 bug。

git add .
git commit -m "fix: xxxxx (bug#123)"
...
git commit -m "fix: xxxx2 (bug#123)"

改完之后推送到test分支。

git pull origin test --rebase
git push origin test

由于 test 环境的编译时定时的，有可能提交之后不能立即看到效果，如果需要线上看到效果，可以将test的改动合并到dev分支，合并方式和上面合并功能分支的方式类似，不再赘述。

修复已发布到外网的 bug

外网出 bug 肯定要在外网的代码基础之上去修改。所以需要从release分支去创建bugfix分支，这里创建分支需要携带 bug 号。

假如禅道的 bug 号是123，首先从release创建bugfix/#123分支。

git checkout -b bugfix/#123 origin/release

然后在bugfix/#123修复 bug，之后提交到远程的bugfix分支，如果没有则创建。

如果想在 dev 环境立即看到修复效果，就合并到 dev 环境中，操作方式上面已经介绍过了，不在赘述。

等到 bug 全部修复结束时，准备发布外网环境，我们需要将远程的bugfix分支合并到release分支并删除bugfix分支。并且把合并过后的release分支再merge到dev和test分支，让 bug 修复在 dev 和 test 环境都生效。

rebase 还是 merge

虽然，rebase和merge都可以合并代码，但是，也不能乱用。

什么时候该用rebase，什么时候该用merge？

牢记一个原则，相同基准的分支，用rebase操作，已经提交到远端的 commit，不要进行rebase。

比如，我从远程的dev分支合并代码到我本地的dev分支，可以使用rebase。

另一种情况，比如我本地有一个分支feature/#xxx是从远程的release分支创建的，我在feature/#xxx新增了一些提交，在 push 到release之前，我们可以去rebase release分支。