各位大佬你们团队开发 git 是如何管理的？

https://nvie.com/posts/a-successful-git-branching-model/

就这个。feature 多 rebase develop 分支。

差不多都是这样吧

gitflow ，代码分支自上而下的同步得写脚本之类的自动进行
冲突在所难免，超过 500 行代码就该提交下进行冲突处理和 code review 了

@miaotaizi 就是想知道还有没有最优解

我是这样的，比如大家代码都合并到 develop 分支。
开发新需求我在本地创建一个新分支比如 feat
开发完后切换到 develop 分支拉取最新代码，然后切换回 feat 分支，合并 develop 代码，有冲突解决冲突
再次切换到 develop 分支，合并 feat 代码，最后推上去

develop> git co -b fat
啪啪啪写代码
feat> git co develop
develop> git pull
develop> git co feat
feat> git rebase develop
啪啪啪解决冲突，add, rebase --continue
feat> git co develop
develop> git merge feat
deveop> git push

服务端开发，我们就比较简单了，开发的起点是 master ，从 master 创建 feature 分支，不同的项目需求创建不同的分支，然后合并到 test 进行测试，上线的时候后把 feature 直接合并到 master 。不过这么做也有一个小问题，大家在功能测试的时候比较容易互相影响，但是总体还是可控的。

如果避免不了很多人修改同一个文件同一处代码，项目结构也得调整吧，靠 git 可能无法解决

“开发的人一多，这样特别容易造成代码冲突”

这个和 git 分支策略没有太大关系，根本问题是在项目本身的结构设计是否合理，功能模块划分是否清晰，每个类的职责是否足够单一。

冲突是在分配开发任务的时候就决定了的，而不是在做分支策略的时候决定的。
如果这些任务对应的代码是不够独立清晰的，那么冲突就是必然的。

@aababc 俺们也是这样

开发前多拉开发分支的代码，不要一次性提交太多代码，多人开发冲突是难以避免的，解决冲突还是要细心。

@weixind 不太适合呀，就是一个项目迭代太多了。I won’t talk about any of the projects’ details, merely about the branching strategy and release management.（我不会谈论任何项目的细节，只会谈论分支策略和发布管理。）

@weixind 就是不太适合呀，就是一个项目里迭代太多了。I won’t talk about any of the projects’ details, merely about the branching strategy and release management.（我不会谈论任何项目的细节，只会谈论分支策略和发布管理。）

@DamonLin 真的是 事在人为

一开始老项目换 Git 时候也遇到类似问题，后面重新整理代码，拆分功能
各自管各自的，冲突也减少，即使有紧急 BUG 或者需求要上都不影响

Google 搜 trunk-based development

@liuchengfeng1 #4 都是在这基础上变，适合自己项目就好。代码冲突是无解的，所以才要将功能拆分到不同文件，用现在的话说，就是分模块。
举例，如果两个人同时要在一个页面做开发，这个页面有个入口文件(index.ts|js)，他们各自写自己模块（ a.ts,b.ts ），在 index.ts 引入这两个文件。基本上冲突就只在 index.ts 出现，只要没人在 index 写大段业务逻辑，可以说基本冲突为零。

@liuchengfeng1 #11 冲突是必然的，要想办法减小冲突的粒度。开发分支要多 rebase develop 分支，多次解决冲突，不要最后堆到一块解决。同时项目模块划分要更清晰。

可以试试 dev 分支 更新了之后要求 各个 feature 分支将 dev 合并到自己分支内部会不会好些

按上线计划拆分分支，而不是一个功能一个分支，也不是一个人一个分支。假定上线计划是一周一发布，那 dev 分支放本周需要上线的内容，如果有内容需要本周开发，但不知道什么时候上线，或者你们上线计划经常变化，那建立单独 dev 分支。每个功能做完之前拉代码，做完立即提交。每个人都这样做，问题就不会太大。

随着人数增加和项目复杂度的提升，解决代码冲突已经不是 Git 范筹的问题，要从项目和人员的组织架构上调整，以及工作流程的重新定义。
- 代码结构要更松散，减少耦合。比如拆分文件和项目，如微服务
- 工作内容的重新划分，比如由以前的一坨进行水平或垂直拆分；由以前的水平拆分，变成垂直拆分；或由以前的垂直拆分变成水平拆分

gitlab flow

尽量少动别人的代码，动了之后就要马上提交，写好注释。

开发：
1 ， 每个人只能从 dev 合并到自己
2. 功能开发 ok 后，才合并到 dev ，并且有专人审核，必须 build ok

bug：
1 ， 牵头人，拉分支
2 ， 所有相关人员的改进，必须有由牵头人负责审核合并，

冲突是必然的，你们尝试过用插件统一格式吗，比如前端项目的 eslint/prettier 。

如果每个人的编辑器配置不同，哪怕只修改一部分代码，整个文件的格式都会乱，这样冲突会更多

每个人新增功能/处理 bug 就建一个个人分支呀，每个个人分支只做一个相关功能的 bug 修复或只增加一个新特性，然后 review 合并到 dev 分支上，之后删除自己的个人分支，循环往复。

如果有 ci/cd 的话，就每天出个包给到测试那边，测试那边去回归测试

最后从 dev 建个 release 分支，给测试用来做稳定性测试、系统测试等等

1 个固定分支：

- **master**：主分支。所有的 feature 和 bugfix 分支都从该分支创建。该分支受保护，不允许直接向该分支提交代码

3 个短期分支，完成功能开发之后需要删除：

- **feature/\***：功能分支。用于开发新的功能，不同的功能创建不同的功能分支，功能分支开发完成并自测通过之后，需要合并到 master 分支，之后删除该分支
- **bugfix/\***：bug 修复分支。用于修复不紧急的 bug ，普通 bug 均需要创建 bugfix 分支开发，开发完成自测没问题后合并到 master 分支，之后删除该分支
- **release/\***：发布分支。用于代码上线准备，该分支从 master 分支创建，创建之后发布到测试环境进行测试，测试过程中发现 bug 需要开发人员在该 release 分支上进行 bug 修复，所有 bug 修复完后，在上线之前，需要合并该 release 分支到 master 分支。release 分支可以长期保留

代码冲突处理在现代 IDE 已经不算个事了吧，图形化操作

直接往 master 干，反正就一个人

我们比较简单粗暴，就在 master 上开发提交，然后 release 的时候再从 master 拉出 release 分支，修 bug 的时候把提交 cherry-pick 到各个需要修复的 release 版本

公共的就一个 master 分支，有新功能或者 bugfix 就自己基于 master checkout 一个新分支，写完后、测试后 merge 到 master ，打个 tag ，根据 tag 走发布

使用 github flow ，其实就是社区玩法，再融合一些企业特点的改变。
master 、release 、test 、dev：分别是部署环境的分支，需要部署才合并上来
n 个 feature 分支：需求开发的分支，理想状态下，需要每个 feature 测试完成再合并到 release 和 master ，但是实际的企业环境可能是多需求单测试环境，所以可以以下操作：
- 开发：测试自己的代码，但是由于依赖其他服务，feature 合并到 dev 分支，部署自测/联调
- 测试：feature 合并到 test 环境，给测试人员过测试用例
- 预发部测试：feature 合并到 release ，部署测试
- 正式发布：feature 合并到 master ，部署

PS：注意每次修复 bug ，到需要在 feature 分支修复，再合并到部署分支，因为需求可能随时回滚，部署分支可能会回退。这个工作流基本满足大部分开发团队和需求情况。

我也想走标准的 git-flow 流，奈何我司是小公司，迭代非常快，要支持这种场景，我司的 git 管理是这样的：只保留 master 这一个维护分支，不设置 dev 分支，多个 feature 分支

前端 12 个开发分支，后端 3 个开发分支，一个需求占一个，上线之前把 master 合并到当前的开发分支就行

不小心按了 enter ，重发：
我也想走标准的 git-flow 流，奈何我司是小公司，迭代非常快，要支持这种场景，我司的 git 管理是这样的：只保留 master 这一个维护分支，不设置 dev 分支，一个 test 分支(支持多个 feature 分支并行测试，冲突是难免的)，test 分支需要周期性删除，重新从 master 分支 checkout ，保证 test 分支不至于过于混乱，测试完毕后，feature 直接合 master 分支。

每一个 需求/bug 一个分支，遵循 [type]/[title] 的分支名：

feat/add-user
feat/enable-rbac
feat/support-kubernetes-deployment
fix/issue-233
fix/npe-error
feat/JIRA-SERVICE-197
hotfix/JIRA-20240808

测试的时候都往某个专门的分支上 merge 或者走 pull request
developer A: branch feat/add-user merge into test
developer B: branch fix/issue-233 merge into test

此时 developer A 早已经准备上线了:
developer A: branch feat/add-user merge into prod （这时候其实可以 git tag ）

上线没问题，feat/add-user 就可以直接删了，或者放着不动，后续如果这个需求有 bug 了，一定不要继续用这个分支，直接从上次发布的分支上 checkout ，继续往返前面的操作就可以了。

永远不要使用自己的个人分支，不要把分支想象的一个很长远的东西；除了主要用于 发布 的分支，其他一切分支都视作临时的分支。你越是用自己个人固定的分支，冲突就越多，因为你总是要把 prod 分支往自己分支上 pull ，何必呢，看着都累。

之前在某美企，分支全都是用的 JIRA ID ，十多年的老项目，几万个历史分支，十几个人的团队，遇到冲突的情况很少。

GitLab Flow + Atomic MR ，小步快跑

@coderzhangsan 你这个 test 分支感觉和 dev 差不多

冲突多，看看是不是代码结构不太合理，为什么很多人要同时改动同一个文件？

@horizon 这个图一看就有问题， 至少要有一个对应线上版本的分支不能每个分支都是一直变动的，可以是 master 也可以是其他。
假如 master 是对应线上版本的，那 master 只能接受来自发布分支(release&hotfix)的合并，原则就是没上线的功能不能合到 master 。hotfix 和 release 可能是并行存在的，那 hoftix 发完同时要合并到 master 和 release ，那这样中间再开 hotfix 以及发布和新开 release 分支均不会漏 hotfix 内容。

学 Linus 呗
每个部门自己拉一个 branch
部门内部再从部门的 branch 拉各自的 feature
完成了就 commit 自己的 feature, 部门负责人就负责 review 然后把 feature merge 到部门 branch
CTO 就负责从部门 branch merge 到 master

如果另外还需要 test 或 release 就都从 master 分

@liuchengfeng1 复杂的有 git workflow
简化版 github flow
没有最优解，flow 最终会取决于实际的组织结构

@jiangzm #41
release 或者 hotfix 对应线上的
master 作为 upstream branch 保持最新

开发从 master 拉 ft ， 然后测试环境 test ，最后上线用 release

我们领导喜欢不同分支间用 beyond compare 合并代码。

@horizon #44 图里面 release 是作为发布分支，master 看着像开发/测试分支。
发布分支在发布阶段还可能是变动的怎么可能对应的是线上呢？
master 保持最新是开发功能的最新吗？那就是常规 dev/test 分支功能了，这个没问题很多团队在 master 上开发。
名字其实无所谓，只要有特定的分支做测试/特定的分支做发布/特定的分支对应线上版本 就够了。

这个图里面 feature 从 master 开出来，然后又合并到 master ，理论上就是作为 dev/test 分支功能作为集成测试分支。如果是作为开发/测试分支用，那 feature 分支就不能从 master 开出来了， 一定是一个对应线上版本的分支。

1. 拆。项目、服务、模块进行拆分，不同代码库
但个代码库避免过多人维护，一般一个代码库 2-3 人维护；若不满足，则拆分代码库

2. master/dev 分支，dev 为开发分支，每个人开发都是直接在 dev 开发
a ） 1 天至少从 dev pull 一次代码（合并，基本不会冲突），子功能开发完（单元测试通过或编译通过），提交 dev
b ）测试后，dev 合并至 master

@xsen 另，个人一般要求团队成员 1-2 天必须提交一次代码

@jiangzm #47
release 所以带日期的呀，又不是只有一个 release 分支
日期对应发布时间的哈
你再理解一下，这套模型支撑过 20 多个人一起开发，没问题的哈。

个人经验：冲突可以从代码设计上解决，而不是 git 工作流上优化，有一些冲突是无法避免，如果经常遇到同一个文件的冲突，我建议从代码结构上进行拆分优化。

永远从 master 新切分支，dev 是一个测试汇总池子，所有改 bug/迭代的分支 等汇聚 dev ，发布 pro 时按需 mr （合并请求） mster ，编译打包发布，永远不从 dev 合并 master 。

@gorvey 这个肯定要统一 eslint 或者 prettier 的配置文件

@0xD800 说的太对，耦合太重了，或者文件太大导致一个人搞不定。

没有比较好的方案，实际上 git 只是个工具，还是要靠人治，制定 git 工作流，其他的分支 要多从源分支反合并，才能减少冲突，而且也无法确保一定就不出错，git 工具是不会出问题的，只要有人参与做的事情，出问题都是人的问题，

建议了解下主干分支+特性开关管理模型，最近两个大项目实践下来感觉还不错。

https://mp.weixin.qq.com/s/m4N8ugQEM-StNRHV2XJ8KA

每天自动把主干分支反向 merge 到各个 feature 分支, 有冲突尽早解决.

如果是多版本发布策略，用 1 楼图片那种，如果是单版本滚动发布就用 gitlab flow

每个小时合并一次主开发分支, 这样就很轻松了

TBD + Feature Toggle

一个 master 分支，一个 dev 分支，开发都在 dev ，自己 fork 一个仓库提 mr 合 dev ，有 committer 和特性责任人检视，自验完打 tag 出包转测试，每个人提交代码要保证自验和正常启动，每次提交不能超过 500 行。发布时从 dev 合 master 。
线上补丁从 master 拉分支出来修改后双合 master 和 dev 。

参考 Releaseflow https://suraciii.github.io/posts/release-flow/

重点：
* 一个主干
* 快速集成
* 自动化测试
* 不要合来合去的

多说一句，gitflow 已经成为了现代软件的一种灾难

简单的项目 gitflow

更快速或者高效的团队可以考虑 github-flow 或者 gitlab-flow 。

有奇葩要求的，也可以自己团队商量一套实践。

但是、但是，总会有 2B 的领导或者不写代码的“技术牛人”，跳出来要求“统一”“规范”，最后搞出个缝合怪。

你这个等所有人在一个分支上开发

你可以在 release 上多分出几个分支，一个 feat 或者一个组分配一个 release 的子分支，结合 gitflow 看看

还是能力问题，git 本身够简单了。有的同事死活搞不懂，已合并就覆盖别人。习惯太差

对于中小公司，真心一劝，像 svn 那样中心化来用 git 是最好的，在满足自身业务版本控制需求前提下，流程越简单越好，血泪教训。

我觉得多人一起开发的时候冲突不可避免，谁后提交，谁解冲突。哈哈。

我好奇这种做完立即提交，算不算 svn 的方式使用 git ，比直接 svn 好在哪儿了呢
@xuld

@panda1001 手下：报告长官，后方发现有敌人来袭。
你：从后方过来算不算偷袭呢？偷袭是不是不道德？偷袭会遗臭万年的。

有“经常冲突” 这个问题说明 代码组织结构 有优化空间。

@xuld 我不是说这样不可以，只是说在项目版本控制的选型上，如果考虑 op 情况和你提供的建议，还选型 git 是想到了哪些优点

建议用 rebase ，不要用 merge ，后期会明了很多

@horizon #50 带不带日期没啥区别，带日期难道就不是发布分支了吗。发布分支在发布阶段还是有可能有 bugfix 。
不是我不理解你那个图一看就明白，确实有问题。应该是你没明白我的意思或者你确实不太懂分支管理流程（对叫流程不叫模型）。

还有不规范不代表一定会有问题，一个分支也可以玩，既然用了 gitflow 流程不妨就对齐标准。1 楼的图是很经典的虽然每个公司会有点差异但核心原则要保持一致的。

@jiangzm #73
我那个写的不是 gitlab flow ？
不争论了，确实我比较菜吧。