左耳听风
陈皓
网名“左耳朵耗子”，资深技术专家，骨灰级程序员
立即订阅
40357 人已学习
课程目录
已完结 108 讲
0/6登录后，你可以任选6讲全文学习。
开篇词 | 洞悉技术的本质，享受科技的乐趣
免费
01 | 程序员如何用技术变现（上）
02 | 程序员如何用技术变现（下）
03 | Equifax信息泄露始末
04 | 从Equifax信息泄露看数据安全
05 | 何为技术领导力？
06 | 如何才能拥有技术领导力？
07 | 推荐阅读：每个程序员都该知道的知识
08 | Go语言，Docker和新技术
09 | 答疑解惑：渴望、热情和选择
10 | 如何成为一个大家愿意追随的Leader？
11 | 程序中的错误处理：错误返回码和异常捕捉
12 | 程序中的错误处理：异步编程以及我的最佳实践
13 | 魔数 0x5f3759df
14 | 推荐阅读：机器学习101
15 | 时间管理：同扭曲时间的事儿抗争
16 | 时间管理：如何利用好自己的时间？
17 | 故障处理最佳实践：应对故障
18 | 故障处理最佳实践：故障改进
19 | 答疑解惑：我们应该能够识别的表象和本质
20 | Git协同工作流，你该怎么选？
21 | 分布式系统架构的冰与火
22 | 从亚马逊的实践，谈分布式系统的难点
23 | 分布式系统的技术栈
24 | 分布式系统关键技术：全栈监控
25 | 分布式系统关键技术：服务调度
26 | 分布式系统关键技术：流量与数据调度
27 | 洞悉PaaS平台的本质
28 | 推荐阅读：分布式系统架构经典资料
29 | 推荐阅读：分布式数据调度相关论文
30 | 编程范式游记（1）- 起源
31 | 编程范式游记（2）- 泛型编程
32 | 编程范式游记（3） - 类型系统和泛型的本质
33 | 编程范式游记（4）- 函数式编程
34 | 编程范式游记（5）- 修饰器模式
35 | 编程范式游记（6）- 面向对象编程
36 | 编程范式游记（7）- 基于原型的编程范式
37 | 编程范式游记（8）- Go 语言的委托模式
38 | 编程范式游记（9）- 编程的本质
39 | 编程范式游记（10）- 逻辑编程范式
40 | 编程范式游记（11）- 程序世界里的编程范式
41 | 弹力设计篇之“认识故障和弹力设计”
42 | 弹力设计篇之“隔离设计”
43 | 弹力设计篇之“异步通讯设计”
44 | 弹力设计篇之“幂等性设计”
45 | 弹力设计篇之“服务的状态”
46 | 弹力设计篇之“补偿事务”
47 | 弹力设计篇之“重试设计”
48 | 弹力设计篇之“熔断设计”
49 | 弹力设计篇之“限流设计”
50 | 弹力设计篇之“降级设计”
51 | 弹力设计篇之“弹力设计总结”
52 | 管理设计篇之“分布式锁”
53 | 管理设计篇之“配置中心”
54 | 管理设计篇之“边车模式”
55 | 管理设计篇之“服务网格”
56 | 管理设计篇之“网关模式”
57 | 管理设计篇之“部署升级策略”
58 | 性能设计篇之“缓存”
59 | 性能设计篇之“异步处理”
60 | 性能设计篇之“数据库扩展”
61 | 性能设计篇之“秒杀”
62 | 性能设计篇之“边缘计算”
63 | 区块链技术的本质
64 | 区块链技术细节：哈希算法
65 | 区块链技术细节：加密和挖矿
66 | 区块链技术细节：去中心化的共识机制
67 | 区块链技术细节：智能合约
68 | 区块链技术 - 传统金融和虚拟货币
69 | 程序员练级攻略：开篇词
70 | 程序员练级攻略：零基础启蒙
71 | 程序员练级攻略：正式入门
72 | 程序员练级攻略：程序员修养
73 | 程序员练级攻略：编程语言
74 | 程序员练级攻略：理论学科
75 | 程序员练级攻略：系统知识
76 | 程序员练级攻略：软件设计
77 | 程序员练级攻略：Linux系统、内存和网络
78 | 程序员练级攻略：异步I/O模型和Lock-Free编程
79 | 程序员练级攻略：Java底层知识
80 | 程序员练级攻略：数据库
81 | 程序员练级攻略：分布式架构入门
82 | 程序员练级攻略：分布式架构经典图书和论文
83 | 程序员练级攻略：分布式架构工程设计
84 | 程序员练级攻略：微服务
85 | 程序员练级攻略：容器化和自动化运维
86 | 程序员练级攻略：机器学习和人工智能
87 | 程序员练级攻略：前端基础和底层原理
88 | 程序员练级攻略：前端性能优化和框架
89 | 程序员练级攻略：UI/UX设计
90 | 程序员练级攻略：技术资源集散地
91 | 程序员面试攻略：面试前的准备
92 | 程序员面试攻略：面试中的技巧
93 | 程序员面试攻略：面试风格
94 | 程序员面试攻略：实力才是王中王
95 | 高效学习：端正学习态度
96 | 高效学习：源头、原理和知识地图
97 | 高效学习：深度，归纳和坚持实践
98 | 高效学习：如何学习和阅读代码
99 | 高效学习：面对枯燥和量大的知识
左耳听风
登录|注册
20 | Git协同工作流，你该怎么选？
陈皓 2017-12-07
与传统的代码版本管理工具相比，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)可以用来在所有的提交中找代码。因为都是本地操作，所以你会觉得速度飞快。
除此之外，由 Git 衍生出来的 GitHub/GitLab 可以帮你很好地管理编程工作，比如 wiki、fork、pull request、issue……集成了与编程相关的工作，让人觉得这不是一个冷冰冰的工具，而真正和我们的日常工作发生了很好的交互。
GitHub/GitLab 这样工具的出现，让我们的工作可以呈现在一个工作平台上，并以此来规范整个团队的工作，这才正是 Git 这个版本管理工具成功的原因。
今天，我们不讲 Git 是怎么用的，因为互联网上有太多的文章和书了。而且，如果你还不会用 Git 的话，那么我觉得你已经严重落后于这个时代了。在这篇文章中，我想讲一下 Git 的协同工作流，因为我看到很多团队在使用 Git 时，并没有用好。
注意，因为 Git 是一个分布式的代码管理器，所以，是分布式就会出现数据不一致的情况，因此，我们需要一个协同工作流来让工作变得高效，同时可以有效地让代码具有更好的一致性。
说到一致性，就是每个人手里的开发代码，还有测试和生产线上的代码，要有一个比较好的一致性的管理和协同方法。这就是 Git 协同工作流需要解决的问题。
目前来说，你可能以为我想说的是 GitFlow 工作流。恭喜你猜对了。但是，我想说的是，GitFlow 工作流太过复杂，我并不觉得 GitFlow 工作流是一个好的工作流。如果你的团队在用这种工作流开发软件，我相信你的感觉一定是糟透了。
所以，我的这篇文章会对比一些比较主流的协同工作流，然后，再抨击一下 GitFlow 工作流。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《左耳听风》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(17)
龍蝦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 48
_CountingStars请问老师的架构图 示意图 是用什么软件画的 感觉很不错2018-01-22 19
Rain分享个小技巧
mac下使用iterm2终端搭配zsh，有非常好用的git快捷键（当然也可以自己alias)，类似gco，gcd，gcm，gl，ggpush，ggsup等等，能少敲不少重复的字符，极大提升效率2018-12-13 9
cellardoor有些人喜欢把事情做的很复杂，以至于看不出有什么问题。有些人喜欢把事情做的很简单，看起来似乎有些问题。2018-01-19 9
王磊git state还是个git stash？作者回复: 写错了，是got stash
2018-06-15 6
jerry Zhou为了避免有 merge 动作，你可以使用 git pull --rebase 。这样就可以把服务器上的提交直接合并到你的代码中，对此，Git 的操作是这样的。 为什么要避免merge动作？2018-08-14 1 5
温LELE🍀几年前，微软终于开始普及Git了，选择的协同工作流是GibHub flow，大大滴改善了生产效率。 读了这篇文章，了解了还有其他工作流方式，还是觉得GitHub简单些，更适合服务化的场景。2019-03-09 4
tao我觉得看团队大小吧。7人以下的团队小而快，直接全部用单master分支就可以，所有人用rebase，防止出现太多分叉。feature分支和bug分支都开发人员自己管理就好2018-06-17 4
浩子耗子哥，写的很在理。是应该在项目本身就开始根据业务进行拆分。再进行监控等2018-01-16 2
小毅皓哥，文章里面的说：一个大型软件会被拆分成若干个服务，那么代码应该也会跟着服务拆解成若干个代码仓库～ 这样随着组里面的项目越来越多，开发维护起来会不会不方便？2018-01-16 2
edisonhuanggit协同工作流的背后，其实隐藏着公司软件架构和自动化软件生产和运维。当采用SOA服务式的架构后，团队自然的被拆分得比较小，在团队内部几乎是采用中心协同工作流的方式，开发迭代速度非常快，而整个系统在paas集成又确保了公司范围内不同组并行协作，从而保证公司级别的人效最大化。
不同的协作方式，工作流模式，目标都在于尽可能的在开发效率和沟通协作两个方面做权衡，让模式尽可能适应团队的规模，从而保证人效的提高。2019-05-31 1
飞扬在百度内部开发使用一种叫做「分支开发分支发布」的工作流，虽然不算银弹吧，但是总的来说比文中提到的更简单清晰一些，也更容易上手，配合agile这个持续集成工具，是我目前见到的最好的协同工作流了。2019-03-21 1- 郎哲我们目前方式 类 「GitLab Flow」小的变动功能上master，稍微负责的打功能分支。在一个目标内打relase版本，fixbug在release上并pick到master。现在遇到 多个项目都对release有要求，然后就变成串行了。正考虑为强要求的项目单独relase和维护。客户端的不干了 说版本太多不发版本容易出错。目前正忍受串行。2018-01-16 1
很大气在实际开发中，如果有并行的需求应该怎样管理分支呢？2018-01-16 1
prader谢谢介绍2019-07-19
jerry我们开发测试uat环境都使用临时分支，会从master分支创建这个临时分支然后把多个功能分支合并到这个临时分支编译发布
整个研发流程大概是功能分支会关联到一个需求项目 这个项目会涉及多个应用的多个分支，当这个需求做完送测的时候会自动找到这个项目下的所有应用和分支，生成一个送测单 当然这个送测单包含了这个项目的所有变更 比如应用代码分支 配置变更 和数据库变更。然后测试通过后会在上线窗口时间批量生成上线单 也是包含所有的变更和一个变更checklist 比如有哪些分支需要合并到master 有哪些配置需要变更 有哪些sql需要执行这样，这些变更一般都是手工执行，最后自动化程序会去检查这些变更是不是执行了，没问题就执行上线流程 发布到uat及发布到生产
当然这些都是自动化程序去做的，只有合并到master 和执行sql是手工执行2018-06-01
C J J嗯，采用什么方式管理代码还是看项目大小，人员多少。2018-04-13
收起评论