2018-01-17Git-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 需要修复。展开 50
2018-01-22请问老师的架构图 示意图 是用什么软件画的 感觉很不错 19
2018-01-19有些人喜欢把事情做的很复杂，以至于看不出有什么问题。有些人喜欢把事情做的很简单，看起来似乎有些问题。 10
2018-12-13分享个小技巧
mac下使用iterm2终端搭配zsh，有非常好用的git快捷键（当然也可以自己alias)，类似gco，gcd，gcm，gl，ggpush，ggsup等等，能少敲不少重复的字符，极大提升效率 9
2018-06-15git state还是个git stash？作者回复: 写错了，是got stash
6
2018-08-14为了避免有 merge 动作，你可以使用 git pull --rebase 。这样就可以把服务器上的提交直接合并到你的代码中，对此，Git 的操作是这样的。 为什么要避免merge动作？ 1 5
2018-06-17我觉得看团队大小吧。7人以下的团队小而快，直接全部用单master分支就可以，所有人用rebase，防止出现太多分叉。feature分支和bug分支都开发人员自己管理就好 5
2019-03-09几年前，微软终于开始普及Git了，选择的协同工作流是GibHub flow，大大滴改善了生产效率。 读了这篇文章，了解了还有其他工作流方式，还是觉得GitHub简单些，更适合服务化的场景。 4
2018-01-16耗子哥，写的很在理。是应该在项目本身就开始根据业务进行拆分。再进行监控等 2- 2018-01-16皓哥，文章里面的说：一个大型软件会被拆分成若干个服务，那么代码应该也会跟着服务拆解成若干个代码仓库～ 这样随着组里面的项目越来越多，开发维护起来会不会不方便？ 2
2019-05-31git协同工作流的背后，其实隐藏着公司软件架构和自动化软件生产和运维。当采用SOA服务式的架构后，团队自然的被拆分得比较小，在团队内部几乎是采用中心协同工作流的方式，开发迭代速度非常快，而整个系统在paas集成又确保了公司范围内不同组并行协作，从而保证公司级别的人效最大化。
不同的协作方式，工作流模式，目标都在于尽可能的在开发效率和沟通协作两个方面做权衡，让模式尽可能适应团队的规模，从而保证人效的提高。 1
2019-03-21在百度内部开发使用一种叫做「分支开发分支发布」的工作流，虽然不算银弹吧，但是总的来说比文中提到的更简单清晰一些，也更容易上手，配合agile这个持续集成工具，是我目前见到的最好的协同工作流了。 1- 2018-01-16我们目前方式 类 「GitLab Flow」小的变动功能上master，稍微负责的打功能分支。在一个目标内打relase版本，fixbug在release上并pick到master。现在遇到 多个项目都对release有要求，然后就变成串行了。正考虑为强要求的项目单独relase和维护。客户端的不干了 说版本太多不发版本容易出错。目前正忍受串行。 1
2018-01-16在实际开发中，如果有并行的需求应该怎样管理分支呢？ 1
2020-01-11在之前的开发过程中，严格执行过一段时间的gitflow. 主要是依赖sourcecode和mac上的tower来进行图形化界面的操作。尽量降低处理各种分支的复杂度。但是尽管如此，还是会出现诸如新来的同事搞不清楚flow导致分支被乱合，常年维护master和develop两个分支，流程太复杂以至于执行不到位等问题。之后我们在gitflow的基础上做了一些简化，去除了release分支，直接用develop做了release. 但是维护成本仍然很高。 流程会议开了很多，也各种邮件进行规范，但的确如皓哥说的，更重要的是把配套工具弄起来让大家不要犯错，而不是一味的纸面规范。
2019-12-14读了之后有个很明显的感觉就是--万事万物没有银弹：
很少有一种工具、方法，适合所有的情况，更多是根据自己的情况挑选最适合的方法。
同时要意识到，环境是在变化、技术在更新，随时有都有可能有更适合当前环境的工具，也随时有可能发生大的环境变化。
关心事物的本质特征，关心工具解决的核心问题，关心工具的核心原理，这样就更容易选择、切换合适的工具来提升效率、质量。
2019-07-19谢谢介绍
2018-06-01我们开发测试uat环境都使用临时分支，会从master分支创建这个临时分支然后把多个功能分支合并到这个临时分支编译发布
整个研发流程大概是功能分支会关联到一个需求项目 这个项目会涉及多个应用的多个分支，当这个需求做完送测的时候会自动找到这个项目下的所有应用和分支，生成一个送测单 当然这个送测单包含了这个项目的所有变更 比如应用代码分支 配置变更 和数据库变更。然后测试通过后会在上线窗口时间批量生成上线单 也是包含所有的变更和一个变更checklist 比如有哪些分支需要合并到master 有哪些配置需要变更 有哪些sql需要执行这样，这些变更一般都是手工执行，最后自动化程序会去检查这些变更是不是执行了，没问题就执行上线流程 发布到uat及发布到生产
当然这些都是自动化程序去做的，只有合并到master 和执行sql是手工执行展开
2018-04-13嗯，采用什么方式管理代码还是看项目大小，人员多少。