我有一个 repo,有开发分支。两个开发人员在他们的分支上工作,b1 和 b2 都来自开发分支。工作和完成后,继续将更改推送到原点。然后将这些分支 merge 到原点开发(Bit-Bucket)。
我想问一下,在每次 merge 之后,对他们的分支进行 Rebase 开发是否重要?或者只是继续进行越来越多的提交和推送,直到完成该功能?什么是正确的策略?
最佳答案
没有“正确”的策略。
每当开发分支有新的提交时,他们可以将他们的 b1/b2 分支 rebase 到开发分支上。这有两个好处:
- 立即分批修复 merge 冲突。
- 开发人员确信他的代码适用于在开发他的功能时推送到远程的任何内容。
或者,他们可以分支出开发分支,在 b1/b2 上实现他们的功能,并且在完成该功能之前不做 rebase 。这有一个好处:
- 在开发功能时不会遇到 merge 冲突等问题,让他们更专注于手头的任务。
但是这也有两个缺点
当他们的功能完成时,他们需要在最后 rebase 。他们不知道在此期间对开发分支进行了多少次提交,这可能使这成为一项艰巨的任务——要 rebase 的提交越多,潜在的 merge 冲突就越多,它就越困惑,工作就越多。
同时 merge 到开发分支的代码可能会破坏它们在其功能中所依赖的代码。
这实际上取决于您/他们希望如何工作。他们希望自己的工作流程不被打扰吗? -> 最后 rebase 一次。他们是否希望确保他们的代码可以与同时推送的任何内容一起工作? -> 经常 rebase 。
关于git - rebase 很重要吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/33097050/