Closed fasheng closed 8 years ago
那 dde-control-center 原来的 master 怎么办? 两个分支都是独立的,而且原来那个分支还在2014版本上用着
不用担心, 2014 的维护分支是 maintain/2014 不是 master
看来还是让 @hualet 和我统一处理好了,会在原master分支最新提交打一个fallback tag(具体名字还没想好),这样也可以避免 @sbwtw 提到的问题,可以为后期需要时创建维护分支留后路 @snyh
确定一下以后以master为主要活跃分支,其他分支项目负责人自己处理,这样有什么问题么? @fasheng
没有问题啊, 以后项目负责人自己管理分支就好. 简单的说, 这次就是要把代码合并回 master 而已.
OK,明天我就可以帮忙推进这件事情,我也早想这么干了,这样给不熟悉的项目提交代码就不用看branches.json的内容了 :joy:
@fasheng pkg_debian你统一改了吧,不然pkg_debian等下就有一大堆cr了
好, 今天上午就会开始处理这个任务, 会统一更改 branch.json
我负责的几个项目已经提交了,深度音乐我看 @iceleaf916 之前已经合并过了,所以就没有处理了。
@pangpangpang3 的我也已经帮忙处理了。
Thanks @hualet :)
dde-control-center 已经合并
Thanks
@Iceyer 不确定 plymouth-theme-deepin 上那个分支是最新代码,有时间你自己处理吧 以及 team-robots, @choldrim 前不久刚刚做了 rebase 操作,先不合并分支了。
目前正在审核 pkg_debian,若没有问题,后面会手动依次触发打包.
以后大家把代码提交到 master 分支就可以了 :)
git review master
@fasheng plymouth-theme-deepin 已经处理完了
目前来看, 配合 code review 和 git tag 直接在 master 分支进行项目开发应该没有太大问题, 趁着现在 gerrit 上的cr不是太多, 准备统一把最新代码(release, develop)合并回 master, 同时使用 master 分支作为开发者源的默认打包分支. 其他特性分支(feature)和旧版本维护分支(release/xxx)则按需创建.
因为合并分支可能会出现冲突, 建议由各项目负责人自行处理, 以 dde-control-center 为例, 步骤如下:
合并分支
注: 1 和 2 review 通过后, 建议先提交 pkg_debian, 否则需要手动触发一次打包如
任务列表 如果觉得操作太复杂, 可以直接编辑贴子把任务分配给我, 我的任务会 放到最后处理 :)
@XuShaohua
@hualet
@sbwtw
@pangpangpang3
@kosl90
@jouyouyun
@Iceyer
@fasheng
过期项目, 放到最后处理
下面的项目相对特殊, 无需处理
待定
@leaeasy @gs342
Q&A
合并分支时, gerrit 上未提交的 cr 如何处理?
建议先把 cr 处理完毕再合并分支, 或者分支合并完成后, 到 gerrit 页 面把受影响的 cr依次 cherry-pick 到 master 分支, 然后将旧的 cr 关闭
分支合并到 master 后, git review 时不小心把代码提交到旧分支该怎么办?
两种方法:
git commit --amend
更改 Change-ID 后重新 git review, 然后将旧的 cr 关闭@linuxdeepin/app-team @linuxdeepin/dde-team @linuxdeepin/system-team