在开发中，正确使用 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。文章来源：https://www.toymoban.com/news/detail-492279.html
另一种情况，比如我本地有一个分支feature/#xxx是从远程的release分支创建的，我在feature/#xxx新增了一些提交，在 push 到release之前，我们可以去rebase release分支。文章来源地址https://www.toymoban.com/news/detail-492279.html
到了这里，关于git开发流程的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
