git-flow

新增一个功能或者修复一个 bug 的时候，都新开一个分支，搞定以后回到 master 再 merge

http://nvie.com/posts/a-successful-git-branching-model/

Git 分支管理策略 http://www.ruanyifeng.com/blog/2012/07/git.html

也看过 git-flow，但是通常不同的提交之间一般都会有依赖的，这样 如图中 http://nvie.com/posts/a-successful-git-branching-model/ 中的两个分支之间就会有 merge 的过程，如果经常 merge，那两个分支不是就没用了？

#5 楼 @zlx_star 依赖是指什么？

我现在 2 人开发一个新项目，一个 master 分支，然后两人分别负责前后台各一个分支，前后台分支不断 merge --no-ff master，解决冲突后 checkout master & merge --no-ff feature。

关于分支有个疑问，比如我在 master 下面创建了一个 develop 分支，然后通过 git checkout develop 到 develop 分支下去开发，但是当我通过 git checkout master 换回到 master 分支下的时候，用 git status，还是能看到我在 develop 下修改的文件？难道开分支一定要重新换到另一个目录下才行吗？

#7 楼 @cdredfox 你的变更没有提交到 develop 分支，git 当然给你留着了。这种情况下，如果你的修改是完整的，可以直接在 develop 下 commit，然后 checkout 到 master 就没有那些内容了，如果你的修改不完整，git 还提供了一种机制用于临时保存：stash，具体去 google 吧

哦~明白了，谢谢~

#6 楼 @Rei 比如说某一个功能依赖于前一个功能或者 某个 bugfix。如果将 bugfix 单独放在一个分支，那就要 merge 一下才能保证每个分支都是可工作的。

#2 楼 @Teddy +1

#10 楼 @zlx_star bugfix merge 进 develop 分支，然后到 feature 分支把 develop merge 进来。

我喜欢在 merge 之前，先 rebase 一下

#12 楼 @Rei 有点明白了，这样每个分支的 log 会很清晰。那是不是每次在一个 branch 上开发都先把 develop merge 过来。 #13 楼 @ery 这个时候 rebase 可以用来做什么？我只在修改历史 log 时用过它

#14 楼 @zlx_star 项目刚开始的时候是频繁 merge，大概一天 merge 1 ～2 次。到上线以后就不太会出现两个分支互相依赖了，因为可以按功能划分，有依赖的都在同一个分支。早期因为架子还没成熟，就会相互依赖，这时候通过一个主线分支（主开发分支）来作为 merge 的中心，而不是 branch 之间互现 merge。

如果，直接 merge，那么结果是 log 路线错综复杂。 如果，在 merge 前，rebase 一下，然后再 merge， 那么，最后 log 的只有一条线，而不是多条线，

这是没用 rebase 的效果

这是用了 rebase 后的效果

你喜欢哪个？

#15 楼 @Rei 了解，thx

#16 楼 @ery 当然是后者，呵呵

那就试试 rebase 吧

#17 楼 @zlx_star #18 楼 @ery

rebase 适合于少量的补丁性质的 commit，不要把已经提交到公共区域的分支 rebase。

#19 楼 @Rei 我没有理解，"不要把已经提及到公共区域的分支 rebase" 什么是 公共区域 啊？

#20 楼 @ery 比如 B 分支有两个人在上面开发，然后把 B rebase A。

这里有详细例子 http://git-scm.com/book/zh/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%9A%84%E8%A1%8D%E5%90%88

一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作。
如果你遵循这条金科玉律，就不会出差错。否则，人民群众会仇恨你，你的朋友和家人也会嘲笑你，唾弃你。

#21 楼 @Rei 谢谢，我明白了。 我们的情况如下： 如果，B 分支有两个人在上面开发， 那么，B 分支一定是 master 分支。

我们的原则如下： 只能 其他分支 rebase master 绝不能 master rebase 其他分支

#22 楼 @ery 我这推广了一段时间 rebase，现在组员对 git 熟练起来后，开始提倡 merge 和 rebase 并用。rebase 用在短小的补丁 commit 上，merge 用在特性开发，因为希望 logs 不单要线索清晰（merge 点不要太多），也要反映协作情况（多线进行），不然一个两天前的 commit rebase 到了今天的 commit 上，以后查看起来会很奇怪。

#23 楼 @Rei 我明白你的意思啦，我们只追求线条清晰，不追求协作情况。哈哈

@saito gitlab 的 merge quest, 审批的时候如果选 delete source branch,,, 这个效果与 --no-ff 一致么

#25 楼 @jeffery9 delete source branch 跟 --no-ff 没关系。

merge request 的 merge 默认是 --no-ff 的。