Git 团队开发，可持续发布的最正确的姿势是？

gitflow

楼上正解

develop 放开发中的代码，master merge develop 后打 tag 发布

但是部署不要直接 pull master，而是去 pull 特定的 tag

一些功能可以在另一个分支开发, feature/x

搞懂 Git Flow 的理念，实际流程可以自己定。

master 分支用来上线，develop 分支用来开发，能随时上线的代码才能直接在上面开发，不能上线的代码需要新开分支。master 只从 develop 分支上 merge 代码，尽量避免其他操作。

@akrf #6 一个能需要 6 个月完成，一个功能需要 3 天完成。一起在 develop 上开发？然后合并的时候岂不是还有正在开发的需求。

@swulling #3 没特别清楚 tag 的具体作用。假设同一个文件，譬如就叫 IndexController 吧。
tag 1.0 成员 A 在 IndexController 有一个 function a 在文件 110 行
tag 2.0 成员 B 在 IndexController 有一个 function b 在文件 110 行
同时发布，如何是好？

@caniuse #4 假如功能 A 依赖功能 B 怎么办？

要正规的，得上 gerrit

http://nvie.com/posts/a-successful-git-branching-model/
一直觉得这个文章里面说的是最好的办法，
其实就是 dev 存放开发的完成版，master 存放上线版
然后添加任何功能都有自己的分支，然后 Hotfix 修复也有修复的分支
如果你不想太麻烦，把 hotfix 的分支独立出来其实就够了

@SharkIng 其实就是一楼说的 git flow 的文字解释.. plugin 可以看这里 https://github.com/nvie/gitflow

@cevincheung tag 是 commit 粒度的

Github Flow 简单些。

1. Fork upstream project
2. Create branch for feature/issues/task.
3. Create a pull request
4. Peer Code review( and refactor code according to feedback, till everything is agreed by team members)
5. Merge into upstream/master, apply CI/CD process and deploy to production.
6. Delete your branch. Prepare for next task.

GitFlow 相对比较复杂，虽然有扩展指令支持，但几乎需要专门人员维护其生命周期，合并，发布等。

当然我觉得最重要是 写测试， 写测试， 写测试。

CI 服务器每次 PUSH 能够运行所有测试，最终通过与 CI / CD 服务器配合，实现部署自动化。

在国内几乎所有公司都是想当然的认为写测试浪费时间，所以代码 Broken 而合并到 Master 的情况不见。当然我也遇到 一些人把 GIT 当成 SVN 来用，根本就没用过 Branch。

@cevincheung 无论是六个月还是三天的需求，只要不能随时上线（随时上线：只要 commit 到了 develop 分支上，就默认可以由别人来上线），就必须开新的分支来开发。否则，如果可以随时上线，则直接提交到 develop 分支即可。为什么这么操作？因为别人随时有可能会合并代码到 develop 分支上并上线。

Github Flow + 写测试代码

同问

@swulling #3 就是要有个发布服务器，手动拉下来再 rsync 同步过去，需要 build 的触发 build 事件各个服务器分批次 build ？