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

2017-07-15 19:43:31 +08:00
 cevincheung

十多个人的规模,使用 Gogs 在某云上自建 Git Server 做团队开发。 现在的模式是,项目开两个分支,一个 master、一个 develop。开发在 develop (其实更像是在用 svn ),功能都 ok 了就合并到 master,然后生产环境 webhook 直接 pull 并进行 build。

现在面临一个问题,第一个大版本马上就要正式对外发布并公测了。 再以后一些正在开发中的功能、开发一半的功能可能也会在 develop 中,再按照老路子肯定是不行了。

大佬们最简单易行和最正确的可持续发布的 Git 使用姿势是?

4049 次点击
所在节点    git
19 条回复
devilyaos
2017-07-15 19:53:45 +08:00
gitflow
Kilerd
2017-07-15 20:03:59 +08:00
楼上正解
swulling
2017-07-15 20:30:11 +08:00
develop 放开发中的代码,master merge develop 后打 tag 发布

但是部署不要直接 pull master,而是去 pull 特定的 tag
caniuse
2017-07-15 20:46:25 +08:00
一些功能可以在另一个分支开发, feature/x
cxbig
2017-07-15 20:58:59 +08:00
搞懂 Git Flow 的理念,实际流程可以自己定。
akrf
2017-07-15 21:06:00 +08:00
master 分支用来上线,develop 分支用来开发,能随时上线的代码才能直接在上面开发,不能上线的代码需要新开分支。master 只从 develop 分支上 merge 代码,尽量避免其他操作。
cevincheung
2017-07-15 22:45:34 +08:00
@akrf #6 一个功能需要 6 个月完成,一个功能需要 3 天完成。一起在 develop 上开发?然后合并的时候岂不是还有正在开发的需求。
cevincheung
2017-07-15 22:50:09 +08:00
@swulling #3 没特别清楚 tag 的具体作用。假设同一个文件,譬如就叫 IndexController 吧。
tag 1.0 成员 A 在 IndexController 有一个 function a 在文件 110 行
tag 2.0 成员 B 在 IndexController 有一个 function b 在文件 110 行
同时发布,如何是好?
cevincheung
2017-07-15 22:55:36 +08:00
@caniuse #4 假如功能 A 依赖功能 B 怎么办?
jigloo
2017-07-16 00:26:37 +08:00
要正规的,得上 gerrit
SharkIng
2017-07-16 01:10:40 +08:00
http://nvie.com/posts/a-successful-git-branching-model/
一直觉得这个文章里面说的是最好的办法,
其实就是 dev 存放开发的完成版,master 存放上线版
然后添加任何功能都有自己的分支,然后 Hotfix 修复也有修复的分支
如果你不想太麻烦,把 hotfix 的分支独立出来其实就够了
SharkIng
2017-07-16 01:12:29 +08:00
@SharkIng 其实就是一楼说的 git flow 的文字解释.. plugin 可以看这里 https://github.com/nvie/gitflow
swulling
2017-07-16 02:47:38 +08:00
@cevincheung tag 是 commit 粒度的
hantsy
2017-07-16 10:28:41 +08:00
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 相对比较复杂,虽然有扩展指令支持,但几乎需要专门人员维护其生命周期,合并,发布等。
hantsy
2017-07-16 10:38:03 +08:00
当然我觉得最重要是 写测试, 写测试, 写测试。

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

在国内几乎所有公司都是想当然的认为写测试浪费时间,所以代码 Broken 而合并到 Master 的情况不见。当然我也遇到 一些人把 GIT 当成 SVN 来用,根本就没用过 Branch。
akrf
2017-07-16 10:47:13 +08:00
@cevincheung 无论是六个月还是三天的需求,只要不能随时上线(随时上线:只要 commit 到了 develop 分支上,就默认可以由别人来上线),就必须开新的分支来开发。否则,如果可以随时上线,则直接提交到 develop 分支即可。为什么这么操作?因为别人随时有可能会合并代码到 develop 分支上并上线。
calpamomo
2017-07-16 11:28:22 +08:00
Github Flow + 写测试代码
wujunze
2017-07-16 12:14:02 +08:00
同问
cevincheung
2017-07-16 12:28:34 +08:00
@swulling #3 就是要有个发布服务器,手动拉下来再 rsync 同步过去,需要 build 的触发 build 事件各个服务器分批次 build ?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/375604

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX