git 临时修改 bug 要怎么创建分支

你要修复到哪个分支，就从哪个分支 checkout 出来一个新的修复分支。

如果这个 bug 影响到了你的 dev 的开发，那么你在提交测试完 test-bug 分支且合并到 test 之后，dev 合并 test 分支以修复这个 bug
如果不影响，就放那吧

不要直接合并 test-bug 进 dev，虽然不会提交两遍（参见 git 原理）
但是会导致同一个提交有两个提交记录。

记住，你的 dev 永远只 follow 一个分支准没错。

您可以参考下 git flow 的流程 https://danielkummer.github.io/git-flow-cheatsheet/index.zh_CN.html

我们以前的版本控制更复杂一些，除了你说的三个分支以外每次开发提的正式需求要从 master checkout 对应的 feature 分支，开发后再合并到 dev->test 提测，然后你说的这种情况就会在 dev 分支修改 bug 提交，再合并到 test 分支，而其他人没开发完的则还在他们的 feature 分支，不会影响

@phpfpm 你说的“dev 合并到 test 分支以修复这个 bug”，意思是切换到 dev 分支，然后从 test 归并过来吗？

@luxinfl ？？？
多去看看 2 楼给的文档参考。

在 dev 上分支 merge test

@phpfpm 我是看了提交记录，有两个一样的，我以为是重复提交了。。。反正现在合并代码的时候，经常有很多以前提过的代码，而且都是没变化的。。

@Lonersun 谢谢老铁

如果我理解没错，你应该 test 分支拉出来 test-bug 分支修复后，test-bug 合并进 test，然后 test 分支发版后(生产环境)会进入 master，master 会进 dev，dev 完成后会进 test，这个流程最好是这样的一个顺势：dev->test （ test-bug->test ）->master->dev

@guanerlin 我们现在都还没有到 master 分支呢，只是 test 分支发现了 bug 。

@phpfpm 看了文档了，我们没用 git flow 。。。正常提交的流程都差不多

master 上拉一个 hotfix/xxx.xxx 版本的分支，修好了以后，发布
发布完，合并到 master + develop 分支。

参考 git-flow

@luxinfl 可以不用，但是要做正确的事情。。

首先你要理解 git

我们流程是 develop 是用来线上发布的, master 是用来存稳定版本的. 如果需要开发一个新功能 从 master 拉一个功能开发分支: feature-xxxx-yyyyMMdd. 开发完成后提测阶段合并到 beta 分支, 提测完成后 feature-xxxx-yyyyMMdd 分支合并到 develop 用来发线上, 稳定后 develop 再合到 master 存档.

test-bug 合并后, 切到 dev, 把改动 cherrypick 进来直接推

cherry-pick 是正解。

@phpfpm 有几个问题请教下
codereview 是在 feature 开发完成合并到 develop 分支时进行么？
release 分支可以同时有多个么？（几个 feature 并行开发上线）
如果一个大的 feature 到 release 时，在测试期间，有别的并行的小 feature 想上线怎么办？

从主分支上切一个 hotfix 分支

@joesonw 用了 cherrypick，但是我发现单独拉个 bug 分支，好像也不怎么影响。有 bug 就在 bug 分支上面改，dev 分支还是照常开发。。。我们反正没搞的太细致

@newtype0092

1 codereview
本质上 cr 是说不要让不合格的代码影响到其他人，所以合并到公共分支必须经过 cr
2 release 分支的个数
不行，一部分机器上 A 一部分机器上 B 么。。一般是梯度上线（小流量，灰度，每个层次有专门的分支）
3 小 feature
我们都是 release 分支不会持续太久（小流量也好灰度也好预发布也好持续太久必然导致功能分裂）
所以要么等 release 测完再上（一般的，realease 正在被用着的时候不允许其他需求合并到 release ）
要么，后上的想上线先上的还没 ready 怎么办
或者线上的想上线后上的还没 ready 又该怎么办
不合并的自由度高一些。

紧急修复直接上 master 。

我觉得需要从 dev 分支拉一个新的 bug 分支来处理，毕竟这个 bug 跟 test 分支的任务是无关的，最终合并分支时可以直接合并到 dev 也可以先合并到 test 再合并到 dev，这样更灵活

我把 test 、dev 搞反了，你说的方式是对的，bug 没有被提交两遍，最终的 commit history 中只有一个 commit 跟 bug 相关，其他的都只是 dev 的 commit，所以没关系

test 切出 bugfix 分支，改完后合并回 test，再 merge test 到 dev

可以看下文档 https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

分支只是 commit history 中某个 commit 的引用，跟 svn 的方式不一样的

一般哪里有 bug 就改哪里。如果想避开提交记录的重复，可以从 dev checkout 出去，改完 squash 进 dev，然后 merge 进 test，这样看上去会清晰一些。

dev:git stash
dev:git checkout test
test:git checkout -b test-bug
test-bug:git push
test-bug:git checkout test
test:git merge test-bug
test:git checkout dev
dev:git merge test

如果哪一步不对，还请指正

遵循 gitflow 吧

提交到 dev，然后 cherry pick 到 test

从有 bug 的分支 checkout 出来一个 hostfix/xxxx 的分支，修改提测没问题合并到该分支以及基于该分支的其他分支。

@ferock 在测试阶段发现的 bug 是 bugfix

@luxinfl 我的意思是，流程是这样，所以你不要考虑这个分支往 dev 流动

@admin7785 额，最后一步和你不太一样，我是 dev:git merge test-bug

@faceRollingKB 最后从 dev 合到 test 的时候，会有 test-bug 合到 dev 的记录。。我记得是这样的

@faceRollingKB 看了一下，发现其实 test-bug 分支不需要去合到 dev 里面，dev 开发完直接合过去，有冲突解决冲突就行了

@admin7785 我看了 git 文档，好像不需要吧 test-bug 合并到 dev 分支，dev 改完之后，直接合到 test 就行了。然后可以拉新的 dev 分支

@luxinfl 最后合并三个分支 dev 、test 、bug 无论什么顺序结果都是一样的，你都需要处理 3 ～ 4 次 merge，一次解决 conflict，另外几次 fastforward 修改 pointer(同步分支引用)，没有拉新 dev 分支的必要

你这种情况属于主干开发，分支发布。
发布分支上发现了 bug，在发布分支上修复，并遴选到主干上。
#33 有 conflict 应该尽早处理，等你过了几个星期开发完 dev 分支，估计都忘了那个 test-bug 了。

前面有人提到 git flow，其实你的 test 分支相当于线上分支，以这样的视角参考 git flow 。

@luxinfl #34 但是不应该是立即切个 test-bug 出来解决 bug 吗，解决完之后还要在 dev 做第二次修改吗？

看了你 33 楼的回复，应该是没问题的，合并的时候解决冲突就行，最后一步合到 dev，可以避免解决冲突这一步，都差不多，我日常中会选择合并。

@admin7785 反正公司也没人会关注提交日志什么的，现在 bug 分支就两头合，无所谓了