git-flow

前几天看了《 Code Review 程序员的寄望与哀伤 》，想到我们团队开展Code Review也有2年了，结果还算比较满意，有些经验应该可以和大家一起分享、探讨。 我们为什么要推行Code Review呢？我们当时面临着代码混乱、Bug频出的状况。 当时我觉得要有所改变，希望能提高产品的代码质量，改善开发团队面临的困境。并且我个人在开发上有很多经验，也希望这些知识能够在团队内传播。 各种考虑后，我们最后认为推行Code Review能改善或解决我们面临的很多问题。 这篇文章的目的不是告诉大家怎么在一个团队内推行Code Review，首先因为我个人仅在一家公司内推行过，并没有很多经验。 其次每家公司、每个团队的情况都不太一样，应该根据公司或团队的实际情况选择恰当的方案，并根据成员的反馈来及时调整，推动Code Review的实施。 所以，本文是介绍我们公司是如何实施Code Review的，我们是如何解决我们遇到的问题的，希望我们的经验能给大家带来些帮助。 行文仓促，如有遗漏或错误，欢迎指正。 一、流程和规则 经过简单的对比、试用，我们最后采用了Git Flow+Pull Request（PR）模式来做Code Review。（PR模式详情可参见 Git工作流指南：Pull Request工作流 ） Pull Request(PR

安装 参考 https://blog.csdn.net/qq_35246620/article/details/61191375 安装过程全程默认（路径和快捷方式自定义，不需要下载jre）； 启动后全程默认，并激活； 配置调优： 1.*.exe.vmoptions:VM 配置文件（内存大于 8G，建议进行修改）; idea.properties:属性配置文件（没有 32 位和 64 位之分）; idea.config.path=${user.home}/.IntelliJIdea/config： 指向 IntelliJ IDEA 的个性化配置目录； idea.system.path=${user.home}/.IntelliJIdea/system： 指向 IntelliJ IDEA 的系统文件目录； idea.max.intellisense.filesize=2500： 提高在编辑大文件时候的代码帮助； idea.cycle.buffer.size=1024： 用于控制控制台输出缓存，建议增大该值或是直接禁用掉，禁用语句为 idea.cycle.buffer.size=disabled； 创建项目 左侧是项目，右侧为SDK，和要添加的框架与库； 下一步，填写项目信息，选择依赖； 文件图标 主要分为三类：Common、Data Sources 、File Types Common

【推荐阅读】微服务还能火多久？>>> GitHub flow 特点 轻量级 分支作为基础 创建分支 基于master 命名是基于功能描述，让团队成员看到你的分支的作用 提交 清晰的说明提交消息，方便查看和回滚 使用Pull Request 任何人都可以确切地看到如果接受您的请求将合并哪些更改 可以审查合并代码 讨论并检查代码 在Pull Request的基础上使用留言社区化谈论 通过讨论提高代码质量 部署 任何分支都可以部署，部署操作在合并master之前 出问题可以回滚 合并 部署之后在生产环境验证 验证没问题之后再合并到master分支 Git flow 由于本文Git flow不是重点所以简要概述 特点 分支作用明确，长时间维护master和develop分支 操作固定，创建功能-完成功能-创建版本-上线版本-创建热修复-完成热修复 没有用到rebase 两者区别 GitHub flow更加简洁，并且要求使用Pull Request，鼓励线上讨论，并且任何一个完成的功能都是在合并master之前上线到生产环境，那么master的作用也就是归档，方便其他人下载，也就是开源的思想 Git flow的限制更多，都是在团队内部操作，更加严谨和规范 点赞 收藏 分享 文章举报 雨果虾滑 博客专家 发布了357 篇原创文章 · 获赞 461 · 访问量 173万+ 他的留言板 关注 来源

DevOps究竟是什么 DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。——维基百科 DevOps是一种文化转变，或者说是一个鼓励更好地交流和协作（即团队合作）以便于更快地构建可靠性更高、质量更好的软件的运动。——Mike Kavis Mike Kavis是美国Cloud Technology Partners公司的副总裁兼首席架构师，他也更加详细地描述介绍说：DevOps是软件开发生命周期（SDLC）从瀑布式到敏捷再到精益的发展。DevOps超越了敏捷，它的关注点是从SDLC中移除浪费。通常情况下，发现浪费或者瓶颈的形式包括：不一致的环境，人工的构建和部署流程，差的质量和测试实践，IT部门之间缺少沟通和理解，频繁的中断和失败的协定以及那些需要珍贵的资源、花费重要的时间和金钱才能保持系统运行的全套问题。 他还看到另一个重复浪费是：一个DevOps团队的第一步通常是决定他们是否应该使用Chef或者Puppet（或者是Salt、Ansible等其他任何热门的东西）。他们甚至还没有定义自己打算解决的问题，即使他们手头的工具可以解决它们。这些团队通常会紧张地构建数千行脚本

简介 MrtfGitFlow4Idea插件是一款基于 mrtf-git-flow 分支管理流程的Idea插件，它最主要的作用是用来简化分支管理流程，最大限度的防止误操作。 在初始化插件之前必须先保证仓库中具有 origin/master 分支。 主要功能如下： 插件配置文件可以加入GIT版本管理，在团队内部共享； 基于 origin/master 新建开发分支和修复分支； 基于 origin/master 重建测试分支和发布分支； 开发完成后将开发分支合并到测试分支； 测试完成后将开发分支合并到发布分支，并锁定发布分支； 发布完成后将发布分支合并到 origin/master 分支； 发布失败将解除发布分支的锁定； 主要解决的问题 新建特性分支操作过程复杂，且容易出错； 提测等环节合并代码出错，老是将测试分支代码带上线； 解决多人同时发布，将未完成预发布测试的代码带上线； 解决发布完成后忘记将代码同步到 origin/master 分支； 发布完成后忘记打Tag； 安装 在线安装 离线安装 下载地址: https://github.com/xiaolyuh/mrtf-git-flow-4idea/releases 插件入口 插件入口有2个： 在Toolbar栏，这个需要显示Toolbar（View->Toolbar） 在Statusbar中 配置管理 每个仓库都需要进行插件初始化

多团队git协同开发流程 一、版本管理的挑战 虽然有这么优秀的版本管理工具，但是我们面对版本管理的时候，依然有非常大得挑战，我们都知道大家工作在同一个仓库上，那么彼此的代码协作必然带来很多问题和挑战，如下： 如何开始一个Feature的开发，而不影响别的Feature？ 由于很容易创建新分支，分支多了如何管理，时间久了，如何知道每个分支是干什么的？ 哪些分支已经合并回了主干？ 如何进行Release的管理？开始一个Release的时候如何冻结Feature, 如何在Prepare Release的时候，开发人员可以继续开发新的功能？ 线上代码出Bug了，如何快速修复？而且修复的代码要包含到开发人员的分支以及下一个Release? 二、基于Git Flow扩展的多开发团队分支协同 常用的分支： • Production 分支 也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改 • Develop 分支 这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支 • Test 分支 这个分支主要是用来对应每个测试环境打包，构建镜像 • Personal分支 开发人员基于主开发分支创建的自己提交代码的分支 三、分支管理 •