封面 作为一名85后的技术男,一转眼10年过去了(一不小心暴露了年龄,虽然我叫18岁fantasy),亲手写代码已经是5年前了,目前主要负责公司的软件产品的规划和设计(所以最近写的东西也主要与设计和产品分析有关)并带着研发团队进行产品落地.偶尔手痒痒写点代码或者和团队讨论一下架构设计啥的,毕竟以前是那么的热爱! 这篇文章主要想写写我所在团队git的使用历程,有些算是回忆吧.~老司机共勉啊~ SVN时代 在刚进公司的时候,那会大家都还在使用svn.代码,原型设计和过程文档都在svn上.大概过了一年…

转 http://www.ruanyifeng.com/blog/2012/07/git.html  作者: 阮一峰 如果你严肃对待编程,就必定会使用"版本管理系统"(Version Control System). 眼下最流行的"版本管理系统",非Git莫属. 相比同类软件,Git有很多优点.其中很显著的一点,就是版本的分支(branch)和合并(merge)十分方便.有些传统的版本管理软件,分支操作实际上会生成一份现有代码的物理拷贝,而Git只生成一个指向当前版…

git 分支策略 将要介绍的这个模型不会比任何一套流程内容多,每个团队成员都必须遵守,这样便于管理软件开发过程. 既分散又集中 我们使用的,且与这个分支模型配合的非常好的库,他有一个“真正”的中央仓库.注意,这个库只是被认为是中央仓库(因为Git是一个分布式的版本控制工具,在技术层面没有所谓的中央仓库).我们将会为这个仓库起名为origin,因为所有的Git用户对这个名字都比较熟悉.  每个开发者从origin拉取和推送代码.除了集中式的推送拉取关系,每个开发者也有可能从别的开发者处拉取代码,形…

近两个月由于个人处于新环境.新项目的适应阶段,没怎么提笔写些文章.中间有好几个想法想记录下来分享,但受限于没有很好的时间段供自己总结思考(也可以总结为间歇性懒癌和剧癌发作),便啥也没有更新.借这个周末闲适的下午和明媚的阳光,决定把近来项目上的CI/CD(持续集成/持续交付)策略以及git分支模型和以前的项目做一下分析比较,希望对各位有所帮助,也能有所思考,尤其是那些期望搭建项目部署流水线或者想了解git分支模型的开发.运维人员.背景  废话不多说,由于近期做了N次release,所以对自己目前所…

用Git进行多人协作开发时,必然会合并代码,解决冲突.然而合并代码也是需要点技巧的,如果对一些关键命令没有理解去使用的话,git的版本演进路线就会变得很乱,从而造成了日后维护的一些麻烦. Git上合并代码有git merge 以及 git rebase 两种方式.下面将深入两者的用法以及对两者的适用场景作个总结. 前置知识点 Master分支:首先,代码库应该有一个.且仅有一个主分支.所有提供给用户使用的正式版本,都在这个主分支上发布.这个分支被称为Master分支: Develop分支:主分支…

A successful Git branching model https://nvie.com/posts/a-successful-git-branching-model/ Git工程开发实践(一)——Git基础 https://blog.51cto.com/9291927/2172454 Git工程开发实践(二)——Git内部实现机制 https://blog.51cto.com/9291927/2173002 Git工程开发实践(三)——Git常用操作 https://blog.51c…

原文链接: Git 分支管理策略 最近,团队新入职了一些小伙伴,在开发过程中,他们问我 Git 分支是如何管理的,以及应该怎么提交代码? 我大概说了一些规则,但仔细想来,好像也并没有形成一个清晰规范的流程.所以查了一些资料,总结出下面这篇文章,一共包含四种常见的分支管理策略,分享给大家. Git flow 在这种模式下,主要维护了两类分支: 主要分支 (The main branch) master develop 辅助分支 (Supporting branch) feature branch…

分支管理策略 下面我们来说一下一般企业中开发一个项目的分支策略: 主分支 master 开发分支 develop 功能分支 feature 预发布分支  release bug 分支 fixbug 其它分支 other 1).主分支 master 代码库应该有一个.且仅有一个主分支.所有提供给用户使用的正式版本,都在这个主分支上发布. Git主分支的名字,默认叫做Master.它是自动建立的,版本库初始化以后,默认就是在主分支在进行开发. 2).开发分支 develop 主分支只用来分布重大版本…

分支管理策略 阅读: 246888 通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息. 如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息. 下面我们实战一下--no-ff方式的git merge: 首先,仍然创建并切换dev分支: $ git checkout -b dev Switched to a new branch 'dev' 修改readme.t…

默认情况下合并分支常常直接使用 git merge 命令,是最方便快速的合并方法.其实这种情况下 git 采用的是 fast forward 模式,特点是删除分支后,会丢失分支信息,好像从来没存在该分支一样,而我们推荐的是recursive 模式,能够保留分支的版本记录. 递归模式(recursive) 创建并切换 dev 分支,提交版本后切换回 master 分支,然后再合并 dev 分支,这不过这一次不再使用 git merge dev 命令: # 创建并切换 dev 分支 $ git ch…