最近正在做 docker 方面的预研，分析很全很到位。感谢

最近正在学习这个 Gradle

还处于入门级，很焦虑

同问，目前正在纠结使用 git+gerrit 还 git+git lab

个人认为 git 归根到底只是一个工具，任何策略、实践能够获得认可的前提是你对业务的深入理解，方能将工具的价值最大化，哪怕是一个不起眼的功能。 如下为鄙人粗见

1. 谈谈你对 git 的一些深入的理解 git 能够对不同层次的版本管理提供灵活多变的功能 (外部拓展)，理解配置管理理解业务才能深入，网上有篇文章我觉得非常不错，“从项目管理角度看软件配置管理”
2. 谈谈你对 feature branch 和 release branch 的理解 feature 和 release 都是为项目服务，存在于项目演进的某一个阶段，feature 对应系统某个阶段里的一个模块，二 release 是一个阶段的节点，可包含小 feature。并和串或者组合都是看工程模式。
3. 采用 git 时应该如何使用分支策略以便支撑大型项目的开发（如上百、千人的开发团队） 确保质量和效率二者的前提下，越简单越好。任何的分支策略依赖于业务交付模式，当你确定了业务模式如开发模式、交付频率、协作模式等因素，才能制定更合理的分支策略。

是的，我现在就遇到这情况，找着合适的人太难。

最近正在研究这个，好东西，顶一个。

现在就 2 个仓库共用这个 Apache，数据也是刚从旧服务器同步过来，之前做过二进制校验。

特地将报错的文件数据都验证了一下，都是没问题的。

“ ThreadsPerChild 1024 MaxRequestsPerChild 5000 ” 进程配置之前已经调高了。

现在遇到问题只能重启，无奈

说白了就是国内国外差了数十年，步子迈大了容易蛋碎了

不能吧，我准备下个月报名去，看看以后能不能有机会转型

大拿 拿到砖了没？

目前互联网这类是偏高，传统公司还是得看能力看资历看公司吧

master 和 release 的的理解是对的，master 是发布基线分支，release 是临时的开发分支，用于发布过程 bug 修复。

DEV 是开发主干，上图中少画了一条线，release 有条往 DEV 合并的线。

[i=s] 本帖最后由 nearness 于 2015-1-22 14:45 编辑

每月规划一次功能集，每周迭代发布上线的分支情况简介： 1 master 分支，用于将发布上线内容基线。 2 DEV 分支，即开发主干，每个月从 master 拉出，功能提交至 DEV，发布时拉出 release 分支。 发布完成后将 release 分支合并到 master，并打上 tag。 3 release 分支，用于发布及其发布过程中 bug 修复。

创始人的回归为携程带来的翻天覆地变化，未来旅游市场竞争蓝海将更惨烈，值得期待。

咋搞定的呢？求分享

我说一个 pull 带来的不便的使用场景 (git+Gerrit 配合） 开发 A、B 分贝拉了一套代码截止节点为 1，A 本地进行了 2、3 提交，B 进行了 4、5 提交 (二者提交有 common 部分)。完了 B 先 push。 A 开始使用 git pull 命令，git 自动 merge 后，开始往 Gerrit push，问题就来了，提示 miss commit changed ID。 由于协作过程经常有这样的修改和提交，导致经常出现这类问题。需要开发自己手动修改 commit 信息才能正常提交。

个人认为使用 pull 会带来 2 个问题 1 git 自动 merge 过程不受控可能导致提交无用的东西入库。 2 出现上述描述的场景，影响提交效率。

这个图不错！借来用用

详尽的搭建指导，顶一个

好东西，顶一个

敏捷说实话在国内的环境真正如宣传那样实行基本不打可能，开内发环境和开发人员素质、管理水平与国外差太多。 我觉得还是一句老话，外来的和尚不定会念经。理念与工具都一样适合自己的才是最好的

最近正在实施研发过程管理，深有感悟，我个人觉得过程管理有 3 个很好的切入点： 1 过程管理范围，这个非常重要。2 找到最容易做出亮点的紧迫的问题。3 沟通 层层实时沟通。 有了这个后，就可以将 CMM 的理论和方法付诸具体实践，实时对阶段成果进行回顾总结改进。

如果没有 Admin 就不能 undo 吗

这个也可以解决多项目共分支时跟踪不同分支 bugfix 同步不错。 有机会了试试

软件项目项目类型{V}{VER1.[VER2]}.[VER3]DateTime[编译次数]

说明：

1. “{ }” 所包围的内容为必选内容。
2. “[ ]” 所包围的内容为可选内容。
3. 软件项目为模块名，如钱包 wallet，项目类型指 H5 还是 WebAPP
4. VER1：1 到 99 的整数。只有当软件的架构体系发生重大变化，或者添加了大量重大新功能时需要修订，每次修订 +1，VER2 版本号复位为 0；例如产品规划产品重大改版升级，在原来 5.8 基础上 +1，升到 6.0.
5. VER2：1 到 99 的整数，初始值为 0，每次修订 +1，VER3 版本号复位为 0，因此 VER3 为 0 时，可忽略掉。该版本号主要用于新功能发布版本标识的维护版本；例如，这适用于产品的修正版或完全向后兼容的新版本。
6. VER3：1 到 99 的整数，每次修订 +1，该版本号主要用于生产发布版本 bug 修复或其他小范围的变更的补丁版本。
7. 编译次数：每编译一次 +1；
8. 关于版本号命名的一些约束： a) 版本内测发布之后，到正式发布之前的版本更新，只更新 Release 号，不更新版本号； b) 版本正式发布后，即正式上线部署之后，除非版本被召回重新发布，其他情况，比如对于修订新增项目功能，都需要升级项目名称。 i. 特例说明 --- 召回说明：在软件版本正式发布之后，若发现版本有特别严重问题，不能继续给客户使用，则进行召回处理，召回后重发的版本，项目名称可以不变，只升级 Release 号。 ii. 注意召回要慎重，召回意味着产线全面升级，生产已应用的版本不许全部升级或回退。因此，除非特别严重问题，一般情况下解决问题都可采用升级补丁的方式。