这是一个创建于 1577 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前有两个分支开发中，一个是 feature/i18n 国际化，另一个就叫 feature/A 吧
最近将这两个分支合并到了 release/test 上进行测试，然后发现 feature/A 需要补充国际化的文案。在这种情况下应该在什么分支上进行修改呢？按照 leader 的说法特性分支应该就在对应的特性分支上修改，但是对于「需要修改的部分依赖多个分支」的情况，各位会如何处理？亦或者是我对 git 工作流存在误解？望诸位解答
 | 1 kiritoxf 2021 年 9 月 26 日 feature/i18n 还没往 master 啥的上面合吧，感觉 release/test 只是个预测试的分支？如果这样的话就在 feature/i18n 上直接改呗 如果需要修改的部分还依赖 feature/A 的话，那肯定不能在 i18n 上改了，因为都没有那部分 如果已经往 master 这种分支上合过的话，原则上合的同时会删掉原分支，这时候再建个 fix 分支改 |
 | 2 dvsilch OP @kiritoxf 是的，目前并没有合到 master 目前需要修改的部分同时依赖 feature/i18n 和 feature/A （因为是 feature/A 的新文案，但 feature/i18n 负责语言切换以及使用插值表达式），这种情况下要如何进行修改才不会打乱 git 工作流，保证分支干净呢？ |
 | 3 xaoflysho 2021 年 9 月 26 日  1 如果是标准的 Git 工作流，是有 develop 分支的吧，先将 feature/A 合并至 develop 分支，然后 feature/i18n 拉取 develop 分支做国际化，完成后合并至 develop 。要发布的 release 分支也是从最新的 develop 分支出来的 |
| 4 dvsilch OP @xaoflysho 原来如此，我这边是少掉一个 dev 的分支，导致我无论怎么想都很奇怪。或许我们 leader 的想法是使用 release/test 作为一个 dev 分支去使用？总之非常感谢！ |
 | 5 liuzhaowei55 2021 年 9 月 27 日 via Android @xaoflysho 如果 develop 中同时有其他的开发代码 feature/i18n 上线就会携带上了。 应该都从线上 release 切出各自开发，一起合到 release/test 分支去测试，如果出现迭代依赖的情况就确认一下对方的上线时间，确保对方比你早上线，可以考虑等对方上线了再 rebase release 然后做这部分需求，或者 merge 对方代码到自己的分支，做这部分开发，只要保证对方先上线就行了。 感觉这和开发中的循环依赖差不多了，尽量避免 |
| 6 xaoflysho @liuzhaowei55 在 Git 工作流中，develop 分支做为保留分支，始终是只合并已完成功能的，也就说，要合并到 develop 分支的 feature 分支，要保证功能完成且项目可正常运行。如果管理严格一些的话，develop 分支还会有权限，要合并至 develop 需要提 PR，并进行 Code Review 。 “如果 develop 中同时有其他的开发代码 feature/i18n 上线就会携带上了。” 这是必然的，develop 分支的作用就是如此，合并所有已完成功能分支，所有新的功能分支、预发布分支都是基于 develop 分支的。 这里 feature/i18n 作为功能分支之一，自然应基于 develop 分支。这样在 feature/i18n 分支中，就可以做所有已完成功能的国际化开发。完成后也需要合并回 develop 分支，feature/i18n 分支删除。下次需要新的国际化开发，从 develop 分支拉取新的 feature/i18n 分支。 “应该都从线上 release 切出各自开发，一起合到 release/test 分支去测试” 不应从 release 分支检出，应从最新的 develop 分支检出。在 Git 工作流中，release 分支是临时分支，基于 develop 分支。在 release 分支完成测试后合并至 master 分支和 develop 分支，release 分支删除。此时，master 分支和 develop 分支代码一致。生产环境代码与 master 分支一致。后面的开发将基于此时的 develop 分支进行。 在 Git 工作流中，一般仅保留 master 和 develop 两个分支，其他分支在完成开发并合并后，将被删除。master 分支上的代码始终与生产环境一致。 “如果出现迭代依赖的情况就确认一下对方的上线时间，确保对方比你早上线” 如果出现此种情况，需要对方先合并至 develop 分支，你才能依赖于对方的工作开发。此时也保证对方功能不会晚于你上线。 “或者 merge 对方代码到自己的分支，做这部分开发” 不建议 merge 至自己的分支开发，这样会导致功能分支混乱，增加 code review 工作。 |
| 7 xaoflysho 2021 年 9 月 27 日 |
| 8 liuzhaowei55 2021 年 9 月 27 日 via Android @xaoflysho 然而现实中不太可能存在一个随时可以上线的 develop 分支，基本是一个迭代相关的项目约定时间同时上线，gitflow 更适合单体项目，多部门协同开发中不太实用。 |
Select Language