左耳听风
陈皓
网名“左耳朵耗子”,资深技术专家
180928 人已学习
新⼈⾸单¥98
登录后,你可以任选6讲全文学习
课程目录
已完结/共 119 讲
左耳听风
15
15
1.0x
00:00/00:00
登录|注册

20 | Git协同工作流,你该怎么选?

适应微服务和DevOps架构
引入环境分支和版本分支
提交Pull Request进行Code Review
在自己的代码仓库中开发
每个开发人员fork官方库的代码
调整软件架构和自动化流程是关键
轻量的协同工作流是常态
特殊情况下使用重的协同工作流
软件架构和开发流程的重要性
稳定和不稳定代码的切换
代码和环境一致性
并行开发
GitLab Flow
GitHub Flow
Hotfix分支用于处理线上Bug-fix
Release分支用于预发布环境
Developer分支用于集成测试
Feature分支用于开发功能
Master分支用于发布环境
Pull Request进行Code Review
分享功能分支代码
隔离各个功能的代码改动
解决代码冲突
提交代码到远程仓库
从服务器同步代码
协同工作流的本质
GitHub/GitLab协同工作流
GitFlow协同工作流
功能分支协同工作流
中心式协同工作流
规范团队工作
管理编程工作的工具
有很多有用的命令
快速切换分支
合并代码时保留变更记录
分布式版本管理工具
Git的协同工作流
Git衍生的GitHub/GitLab
Git的优势
左耳朵耗子:Git协同工作流,你该怎样选?

该思维导图由 AI 生成,仅供参考

你好,我是陈皓,网名左耳朵耗子。
与传统的代码版本管理工具相比,Git 有很多的优势,因而越来越成为程序员喜欢的版本管理工具。我觉得,Git 这个代码版本管理工具最大的优势有以下几个。
Git 是一个分布式的版本管理工具,而且可以是单机版的,所以,你在没有网络的时候同样可以提交(commit)代码。对于我们来说,这意味着在出差途中或是没有网络的环境中依然可以工作写代码。
这是不是听起来有点不对?一方面,以后你再也不能以“没有网络”作为不能工作的借口了。另一方面,没有网络意味着没有 Google 和 StackOverflow,光有个本地的 Git 我也一样不能写代码啊……(哈哈。好吧,这已经超出了 Git 这个技术的范畴了,这里就不讨论了)
Git 从一个分支向另一个分支合并代码的时候,会把要合并的分支上的所有提交一个一个应用到被合并的分支上,合并后也能看得到整个代码的变更记录。而其他的版本管理工具则不能。
Git 切换分支的时候通常很快。不像其他版本管理器,每个分支一份拷贝。
Git 有很多非常有用的命令,让你可以很方便地工作。
比如我很喜欢的git stash命令,可以把当前没有完成的事先暂存一下,然后去忙别的事。git cherry-pick命令可以让你有选择地合并提交。git add -p可以让你挑选改动提交,git grep $regexp $(git rev-list --all)可以用来在所有的提交中找代码。因为都是本地操作,所以你会觉得速度飞快。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了Git协同工作流的本质和适用性,通过对比GitFlow、GitHub Flow和GitLab Flow等不同协同工作流的特点,强调了功能分支协同工作流的重要性以及其对快速迭代式开发流程的适应性。作者指出,团队协同工作的本质在于并行开发、代码和环境版本一致性以及稳定的代码,而软件开发的趋势将导致协同工作流变得更简单。文章强调了软件架构和开发流程的重要性,认为调整软件架构和自动化软件生产和运维流程才是真正简化协同工作流程的根本。总的来说,本文为读者提供了对Git协同工作流的深入理解,强调了在不同情况下选择适合的协同工作流的重要性,为读者提供了有益的指导和思考。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《左耳听风》
新⼈⾸单¥98
立即购买
登录 后留言

全部留言(38)

  • 最新
  • 精选
  • 王磊
    git state还是个git stash?

    作者回复: 写错了,是got stash

    2018-06-15
    14
  • 龍蝦
    Git-Flow 和 GitLab-Flow 都有 release 分支,虽然都称为 release,但作用完全不同。 在 Git-Flow 中,release 是介于 dev 和 master 之间,作用是发布前的准备工作(通常应该是用于更全面测试),从 dev 分叉 release 是为了避免阻塞 dev 分支上继续开发新功能;release 属于临时性分支,准备工作完成后是以 Fast-Forward 方式合并到 master;release 上可能会修复一些 bug,所以还要把 release 合并回 dev;发布软件是从 master 上构建。从名称看,release 应该叫做 pre-release,而 master 应该叫 release 。 在 GitLab-Flow 中,release 是从 master 分叉出来,可能会有多个 release 分支,对应软件不同版本。从 master 分叉一个 release (版本)后,可能发现还需要合入一些新功能,所以通过 cherry-pick 方式从 master 中挑选某些功能,不能直接从 master 合并,因为仅需要 master 上的某些新功能而不是全部新功能。release 属于长期分支,而且分叉以后不会再与其它分支合并。除非某个版本不再维护,不然对应 release 会持续存在,因为发布出去的软件随时可能发现 bug 需要修复。
    2018-01-17
    4
    104
  • cellardoor
    有些人喜欢把事情做的很复杂,以至于看不出有什么问题。有些人喜欢把事情做的很简单,看起来似乎有些问题。
    2018-01-19
    1
    29
  • mgxian
    请问老师的架构图 示意图 是用什么软件画的 感觉很不错
    2018-01-22
    2
    25
  • Rain
    分享个小技巧 mac下使用iterm2终端搭配zsh,有非常好用的git快捷键(当然也可以自己alias),类似gco,gcd,gcm,gl,ggpush,ggsup等等,能少敲不少重复的字符,极大提升效率
    2018-12-13
    23
  • tao
    我觉得看团队大小吧。7人以下的团队小而快,直接全部用单master分支就可以,所有人用rebase,防止出现太多分叉。feature分支和bug分支都开发人员自己管理就好
    2018-06-17
    15
  • 温LELE🍀
    几年前,微软终于开始普及Git了,选择的协同工作流是GibHub flow,大大滴改善了生产效率。 读了这篇文章,了解了还有其他工作流方式,还是觉得GitHub简单些,更适合服务化的场景。
    2019-03-09
    14
  • jerry Zhou
    为了避免有 merge 动作,你可以使用 git pull --rebase 。这样就可以把服务器上的提交直接合并到你的代码中,对此,Git 的操作是这样的。 为什么要避免merge动作?
    2018-08-14
    8
    11
  • 飞扬
    在百度内部开发使用一种叫做「分支开发分支发布」的工作流,虽然不算银弹吧,但是总的来说比文中提到的更简单清晰一些,也更容易上手,配合agile这个持续集成工具,是我目前见到的最好的协同工作流了。
    2019-03-21
    3
    9
  • 绿茶
    Git只是工具,花大把时间还不如花在软件架构上自动化上,哈
    2020-04-24
    5
收起评论
显示
设置
留言
38
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部