Git 工作流的一些经验分享(1)

  • 集中式工作流

  • 功能开发工作流

  • Gitflow工作流

  • Forking工作流

下面针对性说下每个工作流可能使用到的场景和适用性:

集中式工作流

集中式工作流 | center

这种工作方式跟svn类似,它只有一个master分支,开发者会先把远程的仓库克隆到本地,之后的修改和提交都在本地操作,直到在某个合适的时间点将本地的代码合入到远程master。这种工作流比较适合小团队,因为小团队可能不会太多的协作和合流的动作。

功能开发工作流

功能开发工作流

这种工作流关注功能开发,不直接往master提交代码保证它是稳定并且干净的,而是从master拉取feature分支进行功能开发,团队成员根据分工拉取不同的功能分支来进行不同的功能开发,这样就可以完全隔离开每个人的工作。当功能开发完成后,会向master分支发起Pull Request,只有审核通过的代码才真正允许合入master,这样就加强了团队成员之间的代码交流,也就是我们常说的Code Review。

Gitflow工作流

Gitflow工作流

这个工作流其实也是我们团队采用的工作流,这也是很多团队会采用的工作流,它会相对复杂一点,但它非常适合用来管理大型项目的发布和维护,后面笔者也会详细讲下这一块。贯穿整个开发周期,master和develop分支是一直存在的,master分支可以被视为稳定的分支,而develop分支是相对稳定的分支,特性开发会在feature分支上进行,发布会在release分支上进行,而bug修复则会在hotfix分支上进行。笔者也是花了不少时间才熟练掌握整个工作流,期间遇到不少坑,后面会跟大家分享下。

Forking工作流

Forking工作流

Forking工作流对于开源项目贡献者一定不陌生了,它有一个公开的中央仓库,其他贡献者可以Fork(克隆)这个仓库作为你自己的私有仓库,开源项目维护者可以直接往中央仓库push代码,而代码贡献者只能将代码push到自己的私有仓库,只有项目维护者接受代码贡献者往中央仓库发起的pull request才会真正合入。

小结一下

上面已经大致讲了在git当中的四种比较常见的工作流,都是需要开发者去实践理解的。

关于git工作流,只有选用最合适自己团队的工作流才能有效的提高开发效率,上面提到的一些工作流模式都有各自的适用场景,如何选用适合自己团队的工作流得结合团队成员的实际情况,看团队成员对于工作流的理解程度,还有对于工作流的执行程度。

我们团队的一些实践

=========

现在讲下我们团队针对Gitflow的一些实践:

master分支

  • 主分支

  • 保持稳定

  • 不允许直接往这个分支提交代码,只允许往这个分支发起merge request

  • 只允许release分支和hotfix分支进行合流

develop分支

  • 开发分支

  • 相对稳定的分支

  • 用于日常开发,包括代码优化、功能性开发

feature分支

  • 特性分支

  • 从develop分支拉取,用于下个迭代版本的功能特性开发

  • 功能开发完毕合并到develop分支

release分支

  • 发布分支

  • 从develop分支拉取

  • 用于回归测试,bug修复

  • 发布完成后打tag并合入master和develop

hotfix分支

  • 热更新分支

  • 从develop分支拉取

  • 用于紧急修复上线版本的问题

  • 修复后打tag并合入master和develop

大家可能会发现我们这个跟标准的Gitflow工作流有些差别,其实也没有什么标准不标准的,前面说到要结合团队的实际情况,我们团队对于目前所采用的工作方式都是达成共识的,所以有一些差异并没有关系。

说了这么久,还没有一句git命令,那就让大家感受一下吧(感谢Bugly小色熊整理):

1). 首先将远程代码拉取到本地

git clone xxx

git checkout -b develop origin/develop

2).新建feature分支

git checkout -b feature

3).多人在feature上开发,如果中途需要将develop的变更合入feature,所有人需要将本地的代码变更提交到远程

git fetch origin

git rebase origin/feature

git push origin feature

然后由feature负责人rebase develop分支,删除原来feature分支,重新新建feature分支;

git fetch origin

git rebase origin/feature

git rebase develop

git push origin :feature

git push origin feature

这样可以保证feature保持线性变更;

4).feature开发完成后,所有人需要将本地的代码变更提交到远程

git fetch origin

git rebase origin/feature

git push origin feature

最后

总而言之,成功是留给准备好的人的。无论是参加什么面试,都要做好充足的准备,注意好面试的礼仪和穿着,向面试官表现出自己的热忱与真诚就好。即使最后没有过关,也要做好经验的总结,为下一次面试做好充足准备。

这里我为大家准备了一些我在面试后整理的面试专题资料,除了面试题,还总结出了互联网公司Android程序员面试涉及到的绝大部分面试题及答案,并整理做成了文档,以及系统的进阶学习视频资料分享给大家,希望能帮助到你面试前的复习,且找到一个好的工作,也节省大家在网上搜索资料的时间来学习。

毕竟不管遇到什么样的面试官,去面试首先最主要的就是自己的实力,只要实力够硬,技术够强,就不怕面试拿不到offer!

为什么某些人会一直比你优秀,是因为他本身就很优秀还一直在持续努力变得更优秀,而你是不是还在满足于现状内心在窃喜!希望读到这的您能点个小赞和关注下我,以后还会更新技术干货,谢谢您的支持!


《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》点击传送门,即可获取!
8hvf9q-1715764778013)]

为什么某些人会一直比你优秀,是因为他本身就很优秀还一直在持续努力变得更优秀,而你是不是还在满足于现状内心在窃喜!希望读到这的您能点个小赞和关注下我,以后还会更新技术干货,谢谢您的支持!

[外链图片转存中…(img-1sRcuMAd-1715764778015)]
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》点击传送门,即可获取!

  • 4
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值