干货:基于 Git Flow 的 Git 最佳实践(附加解决大家经常碰到的问题)

突然想写这一篇Git的使用心得,主要有几个原因,其一是自己使用Git也有快3年时间了,其间自己经历过一些坑,也有迷茫的时候,在呆过的大大小小的团队中,其实每个人也都并不是Git专家,很多对于流程以及Git本身的理解,还处于一个比较混乱的地带。自己写这篇文章希望能抛砖引玉,在总结自己得失的同时,能给大家带来更深层次的思考。

直接进入主题,经过这么多年的实践,多次想避开Git flow寻找更简单的流程,每次自认为找到了捷径,但事实上都发现有这样或者那样更多的问题,所以,我认为最佳的Git实践,仍然得基于标准的Git Flow,来看看Git Flow的标准模型,下面是大家非常熟悉的图:

来自非常经典的Git flow奠基论文:http://nvie.com/posts/a-successful-git-branching-model/

基于这个Git Flow,我所认为的Git 最佳实践,补充和修复了这么几点:

1.分支一共有5类,名称用 / 来区分是因为Sourcetree里面 / 可以作为一个文件夹使用,命名标准为下面这样:

master

develop

feature/***

release/v13.5

hotfix/v13.2

本地的分支可以有一些其他的命名规则,没关系,但是推到远程的必须是这几种命名规范,最好一字不差,比如不要把release写成Release

2.此Git Flow唯一可以变通的地方为开发的时候非必须一定要用feature分支,比如说一个项目刚开始开发的时候,或者突然发现一个不是特别严重的bug,我现在先修改下,想在下一个版本发的时候一起带出去,这种情况就在develop上面改就行了。

3.与Git Flow的论文略微不同,我倡导的是:一个版本开发完成,需要提测的时候,由各个feature合并到develop,然后在develop上开发自测,修复bug,正式提测的时候,由develop迁出release分支,提测

我个人认为这是一个非常良好的开发模型,伸缩性强,适用于各个规模的开发团队,一个人开发,我也会这么干,20个人的团队,也是没有任何问题的。关于这个模型,如果有任何疑问,都可以关注我的公众号(文章底部),然后给我发消息,我会一一解答。

还有关于之前收集网友的很多问题和疑问,我在这里一一回答下:

1,最经常问的,为什么忽略文件无效

因为Git的忽略文件没有办法对已经纳入版本库的文件生效,解决办法:gitignore里面添加完之后,把本地文件删了,然后commit,push上去,别人再更新,就OK了,下次还有这种类型的文件,就直接忽略了

2,Git可以添加项目中的文件夹权限控制吗

不行,问这个问题的原因是因为很多人把svn的思维搬到Git上来,Git并不是以文件夹为单位来组织的,所以现在大多数公司中UI的图片等资源,像png,psd等文件都是用的svn管理,代码用Git管理。想要用这种权限控制的话,很多人另辟捷径选择用Git的子模块和子数来处理,我感觉也是不太好

3,关于Git客户端

我认为就两种选择,命令行和Sourcetree等全局的客户端软件,TortoiseGit根本不适用,原因就是Git不是以文件夹为组织单位的,Tortoise是依托于文件管理器的操作,所以不对付。然后就是各种IDE的插件,很多人用,我个人也是不喜欢,原因很简单,Git是一种生活方式,并不只是在项目中用用而已

4,关于Git代码回滚

暴力派reset:

本地的分支先(reset)重置到一个commit,然后:git push -f,强推,这种是属于删除commit历史的行为,而且强推需要权限,一般来说master分支默认都不让强推

优点:彻底清除版本库上无用的代码,干净,但是做这种操作的同时,最好本地新建一个分支备份下代码

缺点:误操作的代价比较大

婉约派revert:

git revert HEAD~1(1代表从0到1,回退包含当前commit的两个commit,然后会创建新的commit)

优点:所有历史都在,回退的做法为新建一个commit来回滚之前几个commit的代码

缺点:回退几个commit这个需要手动计算,比较烦

5,cherry pick合并单个提交

cherry pick不能完全合并单个commit,因为每个commit都是建立在前一个commit之上

关于我:Android和JavaEE开发工程师,运营有微信公众号"大土豆爱开发",原则“简单,分享”,涉及的内容包括但不限于JavaEE,Android,Git等,欢迎大家关注,共同学习。

二维码:

时间: 2024-12-22 16:33:19

干货:基于 Git Flow 的 Git 最佳实践(附加解决大家经常碰到的问题)的相关文章

基于ITIL的SCOM监控最佳实践

1.  按照系统类别进行监控 很多朋友在使用SCOM进行监控的时候,往往只是导入管理包,推送代理,并不会思考很多,那么在这种情况下,SCOM在进行监控的时候都是基于缺省的类对象进行监控,比如说Windows计算机,一次就只能以一台Windows计算机的维度去监控,点击一台Windows计算机,下面会是关于这台计算机的进一步信息,比如这台计算机上面的磁盘,CPU,内存,数据库状态. 但是,这种监视方式太狭隘了,而且不便于整体统计,如果企业有很多业务系统呢,每个业务系统下面有很多机器,当企业要统计业

Git分布式版本控制系统最佳实践

今天在高铁闲来无事,决定把我之前遗漏的Git好好整理一番. 首先感谢老男孩架构师班赵班长深入讲解Git,综合自己实践整理而来,特此在今天分享给大家. 笔者QQ:572891887 Linux架构交流群:471443208 1.1Git诞生历史 我想大家还记得Linustorvalds在1991年时发布了Linux操作系统吧,从那以后Linux系统变不断发展壮大,因为Linux系统开源的特性,所以一直接受着来自全球Linux技术爱好者的贡献,志愿者们通过邮件向Linus发送着自己编写的源代码文件,

git flow工作流实际项目实践

公司项目的开发流程主要是这样 代码分为 develop分支 master分支 平时我开发的时候,主要在develop分支上改动 一般来讲,有以下几种改动方式 1.直接在develop上修改代码 这种一般是当前没有大需求,没有其他同事一起开发的情况下为了快速完成一个任务才选择直接改develop上的代码,实际上这种做法不太符合规范 2.开发新功能,新开一个feature分支修改 在feature分支上新建以新功能命名的分支,然后在此分支上开发,功能开发完成即可删除此feature 3.准备新版本发

干货|Mesos分布式集群管理最佳实践

Mesos最开始由加州大学伯克利分校开发,推广于美国版的微博Twitter 是Apache下的开源分布式资源管理框架, 它被称为分布式系统的内核,相当于人的大脑. Mesos-Master是整个系统的"大脑",负责管理接入Mesos的各个framework(由frameworks_manager管理)和slave(由slaves_manager管理),并将slave上的资源按照某种策略分配给framework(由独立插拔模块Allocator管理). 示意图 Mesos-Slave负责

我的Android最佳实践之—— 解决闪空界面问题

进入应用时,由于应用的启动Activity都会有默认的theme,所以会跳一下原始界面,才启动我们定义的theme. 修改这个问题的方法,就是给应用启动的Activity设置一个空的theme.如下面的例子: 联系人启动时的Activity为PeopleActivity ,我们就在manifest文件中设置PeopleActivity 的theme为一个空的theme <activity android:name=".activities.PeopleActivity" andr

从一个前端项目实践 Git flow 的流程与参考

Git flow 出自 A successful Git branching model,这里使用了一个前端项目配合本文稿实施了 git flow 并记录流程作出示例和参考,对 hotfix 与持续部署略有提及,本意是用作公司内部的技术安利.所用源码及文档本身见于 github jusfr/HelloGitflow 前言 Gitflow 是一种 git 分支管理工具——说是思想也不为过,它使用既定策略区分和管理开发.测试.生产环境的代码版本,对测试与持续集成友好,与敏捷.迭代的思路一致. 1 准

Git flow的分支模型与及常用命令简介

Git flow是git的一个扩展集,它基于Vincent Driessen 的分支模型,文章"A successful Git branching model"对这一分支模型进行了描述,其示意图如下: Git flow的源码可以通过以下链接下载: https://github.com/nvie/gitflow 或者,直接输入以下命令安装git flow: apt-get install git-flow 在Windows平台下安装git flow,可以参考<Windows环境下

Git flow 的流程

Git flow 的流程与参考 Git flow 出自 A successful Git branching model,这里使用了一个前端项目配合本文稿实施了 git flow 并记录流程作出示例和参考,对 hotfix 与持续部署略有提及,本意是用作公司内部的技术安利.所用源码及文档本身见于 github jusfr/HelloGitflow 前言 Gitflow 是一种 git 分支管理工具——说是思想也不为过,它使用既定策略区分和管理开发.测试.生产环境的代码版本,对测试与持续集成友好,

Git flow的分支模型与及经常使用命令简单介绍

Git flow是git的一个扩展集,它基于Vincent Driessen 的分支模型,文章"A successful Git branching model"对这一分支模型进行了描写叙述.其示意图例如以下: 上图从左往右看,分别为 - 时间轴.从上往下时间在流逝 - feature分支(玫红).图上有两个feature分支,在这个分支上,进行功能特性的开发 - develop分支(黄色).git flow的主分支.feature分支和release分支都会将代码合并到此分支上 -