ZT 基于git的版本管理思路

【ZT 基于git的版本管理思路】的更多相关文章

ZT 基于git的版本管理思路

http://nvie.com/posts/a-successful-git-branching-model/ 分为5种分支: feature:功能分支,开发人员在此种分支下开发新的功能,开发完成后merge到develop,并删除无用的feature develop:开发分支 master:主分支,最终产品从此分支 feature:功能分支,开发完成后删除 release:发布分支,发布之后删除 hotfixes:修补分支,改bug之后删除…

【书摘】一种基于Git的版本管理方案

本篇摘录自<前端工程化体系设计与实践>一书,笔者认为是一套相对合理的方案,建议团队可以根据实际情况进行调整并增加协作命名规范. master分支--主分支存储已发布版本的源码,不能在此分支进行开发,只能合并release和hotfix分支. hotfix分支--热修复分支用来修复线上紧急Bug,以线上版本对应的master分支为基础新建生成. release分支--预发布分支也称为提测分支,可以在此分支上修复Bug,以develop分支为基础新建,或合并develop分支. develo…

基于git的代码版本管理规范及流程-简版

基于git的简单实用的版本管理规范及流程,包括:代码库的分布.人员角色的划分.代码提交合并流程.代码冲突处理.分支管理. 代码库分类根据代码库分布的位置及作用,分为以下几类: 主库:位于服务端,所有开发的代码最终都要合到主库. 个人代码库(服务端):从主库fork出来,位于服务端.每个人自已开发的代码,由本地的git库push到每个人自己的个人代码库(服务端),再由个人代码库(服务端)合入主加. 个人工作库:位于每个开发人员的开发机器,从个人代码库(服务端)clone到本地.每个开发人员开发的…

基于git diff进行的eslint代码检测

缘起在项目中, 通常都会使用代码检测工具来规范团队的代码风格, 比如eslint.随着代码的不断增加, eslint进行代码检测的时间也越来越久.每次检测的时候, 需要检测的文件和实际检测的文件极度不对称,所以便基于git diff写了这样一个小工具. 源代码启动脚本(lint.sh) #!/bin/bash INFO='\033[36m'; NOR='\033[0m'; ERR='\033[31m'; br='dev'; echo -e "${INFO}run lint now ... j…

利用cocoapods创建基于git的私有库

上一篇文章记录了我利用cocoapods创建基于SVN的私有库的全部过程,今天我再记录一下基于git创建的过程. 整体先说明一下创建一个私有的podspec包括如下那么几个步骤: 创建并设置一个私有的Spec Repo. 创建Pod的所需要的项目工程文件,并且有可访问的项目版本控制地址. 创建Pod所对应的podspec文件. 本地测试配置好的podspec文件是否可用. 向私有的Spec Repo中提交podspec. 在个人项目中的Podfile中增加刚刚制作的好的Pod并使用. 更新维护p…

利用cocoapods创建基于git的私有库Spec Repo

上一篇文章记录了我利用cocoapods创建基于SVN的私有库的全部过程,今天我再记录一下基于git创建的过程. 整体先说明一下创建一个私有的podspec包括如下那么几个步骤: 创建并设置一个私有的Spec Repo. 创建Pod的所需要的项目工程文件,并且有可访问的项目版本控制地址. 创建Pod所对应的podspec文件. 本地测试配置好的podspec文件是否可用. 向私有的Spec Repo中提交podspec. 在个人项目中的Podfile中增加刚刚制作的好的Pod并使用. 更新维护p…