电子商务网站建设评估工具,新公司在哪做网站,吉林省建设安全信息网,禅城网站建设公司价格高效利用一次蹲坑时间#xff0c;看看如何使用Git Flow进行高效开发#xff0c;什么才是Git提交的正确姿势#xff0c;怎样使用GitLab进行Code Review#xff1a;
使用Git Flow高效开发#xff1b;Git提交正确姿势#xff0c;Commit message编写指南#xff1b;使用Git…高效利用一次蹲坑时间看看如何使用Git Flow进行高效开发什么才是Git提交的正确姿势怎样使用GitLab进行Code Review
使用Git Flow高效开发Git提交正确姿势Commit message编写指南使用GitLab进行团队内的Code Review
使用Git Flow进行高效开发
在工作环境中绕不开效率一词由于任何一次版本迭代几乎都是需要整个团队协作的所以高效开发不仅仅是个人效率问题还涉及到整个团队的协作效率。个人开发可以怎么顺手怎么搞怎么开心怎么玩但在团队里协作的时候只一个人顺手开心是不够还需要整个团队协作高效。提高效率一般我们会这么搞
遵守行业内的最佳实践借助工具自动遵循规范
什么是Git Flow
Git Flow是构建在Git之上的一个组织软件开发活动的模型是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具一篇名为A successful Git branching model的博文介绍了一种在Git之上的软件开发模型。通过利用Git创建和管理分支的能力为每个分支设定具有特定的含义名称并将软件生命周期中的各类活动归并到不同的分支上。实现了软件开发过程不同操作的相互隔离。这种软件开发的活动模型被称为Git Flow。
Git Flow备忘清
Git Flow是一个Git扩展集按Vincent Driessen的分支模型提供高层次的库操作, 这个备忘清单展示了Git Flow的基本操作和效果。
Git Flow介绍
Git Flow常用的分支master, develop, feature, hotfix, release;历史分支(master , develop): 相对使用仅有的一个master分支Gitflow工作流使用2个分支来记录项目的历史。master分支存储了正式发布的历史而develop分支作为功能的集成分支。 这样也方便master分支上的所有提交分配一个版本号;功能分支(Feature): 每个新功能位于一个自己的分支这样可以push到中央仓库以备份和协作。 但功能分支不是从master分支上拉出新分支而是使用develop分支作为父分支。当新功能完成时合并回develop分支。 新功能提交应该从不直接与master分支交互;发布分支(release): 一旦develop分支上有了做一次发布或者说快到了既定的发布日的足够功能就从develop分支上fork一个发布分支。 新建的分支用于开始发布循环所以从这个时间点开始之后新的功能不能再加到这个分支上—— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。 一旦对外发布的工作都完成了发布分支合并到master分支并分配一个版本号打好Tag。 另外这些从新建发布分支以来的做的修改要合并回develop分支;维护分支(hotfix): 维护分支或说是热修复hotfix分支用于生成快速给产品发布版production releases打补丁这是唯一可以直接从master分支fork出来的分支。 修复完成修改应该马上合并回master分支和develop分支当前的发布分支,master分支应该用新的版本号打好Tag。为Bug修复使用专门分支让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。 你可以把维护分支想成是一个直接在master分支上处理的临时发布;
借助工具自动遵循规范
Visual Studio有一个Git Flow插件GitFlow.VS, Sourcetree最新版本集成了Git Flow插件这些插件的好处是最大化地简化了命令只有Start Feature、Finish Feature、Start Release、Finish Release、Start Hotfix、Finish Hotfix几个操作其他工作Git Flow自动帮你完成
新建功能分支Git Flow会自动拉取最新的develop分支然后自动从develop分支创建一个新的feature分支完成功能分支Git Flow自动合并回develop分支并默认删除feature分支可以更改默认行为新建发布分支Git Flow会自动拉取最新的develop分支然后自动从develop分支创建一个新的release分支完成发布分支Git Flow自动合并回developmaster分支如果提供tag名称则会自动在master打上Tag并默认删除feature分支可以更改默认行为新建修复分支Git Flow会自动拉取最新的或者指定Tag的master分支然后自动从master分支创建一个新的hotfix分支完成修复分支Git Flow自动合并回developmaster分支如果提供tag名称则会自动在master打上Tag并默认删除hotfix分支可以更改默认行为
Visual Studio有一个Git Flow插件
通过Tools Extensions and Updates Online Search gitflow 安装Git Flow插件 装好插件之后Team Explorer会多一个GitFlow 点击GitFlow后如果是首次点击则会提示初始化操作 初始化之后每次进入GitFlow则会根据状态提供创建或结束feature/release/hotfix分支 再次强调 我们需要借助一个工具帮我们自动化遵循规范比如GitFlow插件。
Git提交正确姿势Commit message编写指南
Git 每次提交代码都要写 Commit message提交说明否则就不允许提交基本上你写什么都行但是一般来说commit message 应该清晰明了说明本次提交的目的。目前社区有多种 Commit message 的写法规范。本文介绍Angular规范这是目前使用最广的写法比较合理和系统化并且有配套的工具。
Commit message 的作用
格式化的Commit message有几个好处。
提供更多的历史信息方便快速浏览可以过滤某些commit比如文档改动便于快速查找信息可以直接从commit生成Change log
Commit message 的格式
每次提交Commit message 都包括三个部分HeaderBody 和 Footer。
type(scope): subject// 空一行body// 空一行footer
其中Header 是必需的Body 和 Footer 可以省略。不管是哪一个部分任何一行都不得超过72个字符或100个字符。这是为了避免自动换行影响美观。
Header
Header部分只有一行包括三个字段type必需、scope可选和subject必需。
type用于说明 commit 的类别只允许使用下面7个标识。feat新功能featurefix修补bugdocs文档documentationstyle 格式不影响代码运行的变动refactor重构即不是新增功能也不是修改bug的代码变动test增加测试chore构建过程或辅助工具的变动 scope用于说明 commit 影响的范围比如数据层、控制层、视图层等等视项目不同而不同。subject是 commit 目的的简短描述不超过50个字符。以动词开头使用第一人称现在时比如change而不是changed或changes第一个字母小写结尾不加句号. Body
Body 部分是对本次 commit 的详细描述可以分成多行, 有两个注意点:
使用第一人称现在时比如使用change而不是changed或changes;应该说明代码变动的动机以及与以前行为的对比;
Footer
Footer 部分只用于两种情况:
如果当前代码与上一个版本不兼容则 Footer 部分以BREAKING CHANGE开头后面是对变动的描述、以及变动理由和迁移方法;如果当前 commit 针对某个issue那么可以在 Footer 部分关闭这个 issue (Closes #123, #245, #992), GitHub这个功能很好用
Revert
还有一种特殊情况如果当前 commit 用于撤销以前的 commit则必须以revert:开头后面跟着被撤销 Commit 的 Header。
使用GitLab进行团队内Code Review
Code Review的工具很多Facebook非常有名的Phabricator已经开源。对于经常玩GitHub的人应该很喜欢GitHub的PR功能很多公司使用GitLab或者Gogs搭建自家的Git服务GitLab的Merge Request功能同样可以用于团队内Code Review。
Branches Protection Setting
如果团队内部需要强制进行Code Review, 那么拥有GitLab管理权限的开发人员可以把Repo设置成只有develop和master分支并把developmaster分支都保护起来不允许任何开发人员直接push到这些分支开发人员只能把Repo FORK成自己的Repo。
Your project Setting Protected Branches 创建Merge Request
协作开发的同事只能通过把Repo FORK 成自己的Repo之后从自己Repo clone到本地然后使用Git Flow开发一旦开发到一个需要Review的点通过Merge Request向主Repo请求合并 Code Review
一旦Merge Request创建成功之后主Repo拥有Code Review权限的人就会收到通知Code Review的时候 打开Open的Merge Request会看到Commits Changes打开Changes可以提交自己的Review建议被Review的人继续根据这些建议在自己的Repo里修改修改好之后提交这时会在自己的Repo里及主Repo的Open Merge Request里看到相应更改因此可以继续Review流程直到Merge Request被合并如下图 Syncing a FORK
因为团队的Repo是多人协作开发的也就是说团队的主Repo会被多个开发人员Fork当每个协作开发的开发人员对团队的主Repo请求Merge Request之后负责进行Code Review的同事进行Review完成代码Review之后会合并到主Repo。这时每个Fork的Repo需要同主Repo进行同步才能拿到最新代码具体操作步骤如下
查看本地Repo是否设置了upstream
D:\repos\Apollogit remote -v
origin http://git.code.oa.com/yingtingxu/Apollo.git (fetch)
origin http://git.code.oa.com/yingtingxu/Apollo.git (push)
如果没有设置则进行设置
D:\repos\Apollogit remote add upstream http://git.code.oa.com/ACD/Apollo.gitD:\repos\Apollogit remote -v
origin http://git.code.oa.com/yingtingxu/Apollo.git (fetch)
origin http://git.code.oa.com/yingtingxu/Apollo.git (push)
upstream http://git.code.oa.com/ACD/Apollo.git (fetch)
upstream http://git.code.oa.com/ACD/Apollo.git (push)
获取主Repo的更新
D:\repos\Apollogit fetch upstream
remote: Counting objects: 9, done
remote: Finding sources: 100% (5/5)
remote: Getting sizes: 100% (6/6)
remote: Total 5 (delta 0), reused 5 (delta 0)
Unpacking objects: 100% (5/5), done.
From http://git.code.oa.com/ACD/Apollo* [new branch] develop - upstream/develop* [new branch] master - upstream/master
合并更新以合并develop为例
D:\repos\Apollogit checkout developD:\repos\Apollogit merge upstream/develop
Updating e0d7ffe..2b7875f
Fast-forwardversion.props | 2 -1 file changed, 1 insertion(), 1 deletion(-)
原文地址http://www.xyting.org/2017/02/19/git-flow-gitlab.html .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
