标签：
当前问题：
项目从分支 develop 分叉一个项目分支 master 去做项目交付，然后后面开始两个分支的开发，时不时 master 修复 bug ，develop 加特性（两者加的文件有交集）
提给 master 的 mr 偶尔也会 cherry-pick 给 develop ，但是偶尔着急的没这么做，现在两个分支大概有四十五个 commit 的差异(老脸一红，打的补丁缺失多，有些是需求变更，项目着急要)，尝试了下 develop rebase master ，发现冲突太多了
想问问有经验的大佬们，这种情况怎么做？
好像最简单的是 git merge ，但是对 merge 有疑虑，担心丢失代码和 git 分支相交太多
还有一种想到的，就是从当时分叉出去的节点的 hashxxxx ，计算哪些没同步提到 develop ，再对这些 commit 做逐步地 cherry-pick 然后提 Merge Request 合并
但模拟了下节点的合并，好像这样最后 develop merge 到 master 也会有冲突，因为 master 多出的节点 A'，会放在 develop 多出的节点 B'上，而 rebase 其实是把 B'放在 A'上，保持一条线
也就是现在想到的方法有三种：
- git rebase (develop rebase master)
- git merge (develop merge master)
- diff 出 master 比 develop 多的 commit ，逐个 cherry-pick 到 develop
两个分支合并的难点在于日积月累产生的大量冲突，这不是具体合并方式能解决的。
git 工作流是在项目推进过程中起作用的，帮助每次迭代快速解决小量冲突，而不是在项目不遵循工作流导致分支管理出问题了，开始想用 git 工作流解决已经产生的问题。这不是 git 工作流的用法，git 工作流的存在是在事前避免这种情况，而不是事后解决这种情况。
无论用哪种方式，最终的瓶颈都是解决冲突，只能靠熟悉这两个分支的开发人员去手动解决冲突，没捷径。
merge 地狱的方式就是不 merge 。在 trunk - release branch 的模式里，所有的 cherry-pick 都是从 trunk -> release branch ，纯单向，不会搞错。
还是以你的项目为例，在 trunk （ develop ，其实应该用 master 更合适）上开发，当需要交付版本的时候，拉出一个 release branch （ master ，其实应该用 release-v1.0 类似的更合适），开始在这个分支上进行针对交付的修改（关闭某些未完成的功能，调整某些版本号标识，比如 VERSION="dev" -> VERSION="v1.0"，etc ）。这个分支就是「专属于该发布使用的」。
接下来看一些具体情况：
Q：发现 v1.0 有 bug 需要修复怎么办？（ hotfix 场景）
A：如果是 release-branch 独有的问题，在 release-branch 上修复即可；如果是 master 上也存在的问题，先在 master 上修复，然后 cherry-pick 到 release-branch 上。
Q：需要在 v1.0 上发布新的功能怎么办？（ release 场景）
A：首先已知所有新功能都应该在 master 上开发，而不是在 release-branch 上。接着需要根据增加新的功能涉及的 commit 范围做出选择，1. 从 trunk 上重新开一个 release branch 分支走完整的发布流程，或者 2. 从 trunk 上 cherry-pick 修改到 release branch 上。
可以看到不管什么场景下，都是 trunk -> release branch 单向的。
对于 git flow ，我其实是不太能理解为什么它是 work 的…… 比如当你需要同时维护多个版本线 (v1.x ，v2.x ）时，git flow 的 main 分支是单线的，怎么办；比如当你在 main 上需要标记 VERSION="v1.0"，从 main 派生出的 develop 分支上需要标记 VERSION="dev"，然后 develop 分支又会在 release 时合入 main 分支（ VERSION 打架），hotfix 分支又会从 main 分支派生出来同时合入 main 分支和 develop 分支（ VERSION 又打架）
标签： 来源：
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。