@
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 工作。