20 | 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
《左耳听风》,新⼈⾸单¥98
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(38)
- 最新
- 精选
- 王磊git state还是个git stash?
作者回复: 写错了,是got stash
2018-06-1514 - 龍蝦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-174104
- cellardoor有些人喜欢把事情做的很复杂,以至于看不出有什么问题。有些人喜欢把事情做的很简单,看起来似乎有些问题。2018-01-19129
- mgxian请问老师的架构图 示意图 是用什么软件画的 感觉很不错2018-01-22225
- Rain分享个小技巧 mac下使用iterm2终端搭配zsh,有非常好用的git快捷键(当然也可以自己alias),类似gco,gcd,gcm,gl,ggpush,ggsup等等,能少敲不少重复的字符,极大提升效率2018-12-1323
- tao我觉得看团队大小吧。7人以下的团队小而快,直接全部用单master分支就可以,所有人用rebase,防止出现太多分叉。feature分支和bug分支都开发人员自己管理就好2018-06-1715
- 温LELE🍀几年前,微软终于开始普及Git了,选择的协同工作流是GibHub flow,大大滴改善了生产效率。 读了这篇文章,了解了还有其他工作流方式,还是觉得GitHub简单些,更适合服务化的场景。2019-03-0914
- jerry Zhou为了避免有 merge 动作,你可以使用 git pull --rebase 。这样就可以把服务器上的提交直接合并到你的代码中,对此,Git 的操作是这样的。 为什么要避免merge动作?2018-08-14811
- 飞扬在百度内部开发使用一种叫做「分支开发分支发布」的工作流,虽然不算银弹吧,但是总的来说比文中提到的更简单清晰一些,也更容易上手,配合agile这个持续集成工具,是我目前见到的最好的协同工作流了。2019-03-2139
- 绿茶Git只是工具,花大把时间还不如花在软件架构上自动化上,哈2020-04-245
收起评论