这是一个创建于 2690 天前的主题，其中的信息可能已经有所发展或是发生改变。
十多个人的规模，使用 Gogs 在某云上自建 Git Server 做团队开发。 现在的模式是，项目开两个分支，一个 master、一个 develop。开发在 develop （其实更像是在用 svn ），功能都 ok 了就合并到 master，然后生产环境 webhook 直接 pull 并进行 build。
现在面临一个问题，第一个大版本马上就要正式对外发布并公测了。 再以后一些正在开发中的功能、开发一半的功能可能也会在 develop 中，再按照老路子肯定是不行了。
大佬们最简单易行和最正确的可持续发布的 Git 使用姿势是？
 |
1
devilyaos 2017-07-15 19:53:45 +08:00 via iPhone
gitflow
|
 |
2
Kilerd 2017-07-15 20:03:59 +08:00 via iPhone
楼上正解
|
 |
3
swulling 2017-07-15 20:30:11 +08:00  4
develop 放开发中的代码，master merge develop 后打 tag 发布
但是部署不要直接 pull master，而是去 pull 特定的 tag |
 |
4
caniuse 2017-07-15 20:46:25 +08:00
一些功能可以在另一个分支开发, feature/x
|
 |
5
cxbig 2017-07-15 20:58:59 +08:00
搞懂 Git Flow 的理念，实际流程可以自己定。
|
 |
6
akrf 2017-07-15 21:06:00 +08:00 via Android
master 分支用来上线，develop 分支用来开发，能随时上线的代码才能直接在上面开发，不能上线的代码需要新开分支。master 只从 develop 分支上 merge 代码，尽量避免其他操作。
|
 |
7
cevincheung OP @akrf #6 一个功能需要 6 个月完成，一个功能需要 3 天完成。一起在 develop 上开发？然后合并的时候岂不是还有正在开发的需求。
|
|
8
cevincheung OP @swulling #3 没特别清楚 tag 的具体作用。假设同一个文件，譬如就叫 IndexController 吧。
tag 1.0 成员 A 在 IndexController 有一个 function a 在文件 110 行 tag 2.0 成员 B 在 IndexController 有一个 function b 在文件 110 行 同时发布，如何是好？ |
|
9
cevincheung OP @caniuse #4 假如功能 A 依赖功能 B 怎么办？
|
 |
10
ldbC5uTBj11yaeh5 2017-07-16 00:26:37 +08:00 via Android
要正规的，得上 gerrit
|
 |
11
SharkIng 2017-07-16 01:10:40 +08:00
http://nvie.com/posts/a-successful-git-branching-model/
一直觉得这个文章里面说的是最好的办法， 其实就是 dev 存放开发的完成版，master 存放上线版 然后添加任何功能都有自己的分支，然后 Hotfix 修复也有修复的分支 如果你不想太麻烦，把 hotfix 的分支独立出来其实就够了 |
|
12
SharkIng 2017-07-16 01:12:29 +08:00
@SharkIng 其实就是一楼说的 git flow 的文字解释.. plugin 可以看这里 https://github.com/nvie/gitflow
|
|
13
swulling 2017-07-16 02:47:38 +08:00 via iPhone
@cevincheung tag 是 commit 粒度的
|
 |
14
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 相对比较复杂，虽然有扩展指令支持，但几乎需要专门人员维护其生命周期，合并，发布等。 |
|
15
hantsy 2017-07-16 10:38:03 +08:00
当然我觉得最重要是 写测试， 写测试， 写测试。
CI 服务器每次 PUSH 能够运行所有测试，最终通过与 CI / CD 服务器配合，实现部署自动化。 在国内几乎所有公司都是想当然的认为写测试浪费时间，所以代码 Broken 而合并到 Master 的情况不见。当然我也遇到 一些人把 GIT 当成 SVN 来用，根本就没用过 Branch。 |
|
16
akrf 2017-07-16 10:47:13 +08:00
@cevincheung 无论是六个月还是三天的需求，只要不能随时上线（随时上线：只要 commit 到了 develop 分支上，就默认可以由别人来上线），就必须开新的分支来开发。否则，如果可以随时上线，则直接提交到 develop 分支即可。为什么这么操作？因为别人随时有可能会合并代码到 develop 分支上并上线。
|
 |
17
calpamomo 2017-07-16 11:28:22 +08:00
Github Flow + 写测试代码
|
 |
18
wujunze 2017-07-16 12:14:02 +08:00
同问
|
|
19
cevincheung OP @swulling #3 就是要有个发布服务器，手动拉下来再 rsync 同步过去，需要 build 的触发 build 事件各个服务器分批次 build ？
|
Select Language