永远使用同一个本地分支可以吗

Question

我们最近从 Team Foundation Version Control 切换到 git。我发现我们的开发团队有一种倾向，希望从本地 master 中创建一个本地分支，将其称为 local-dev，然后永远使用该分支。我们正在使用拉请求流程，因此他们将本地开发推送到服务器上，并向主服务器执行拉请求。

拉取请求完成后，他们删除 server-dev 分支，但保留 local-dev 分支。他们只是将最新版本拉入本地 master，然后将本地 master 合并到 local-dev 中。然后重复这个循环。

这是一件可以做的事情吗？在我的脑海中，我看到由于他们的本地开发永远不会被重新设置基础，所以每次他们发出拉取请求时，他们都会不断地将自第一天以来的所有历史记录推送到服务器上，并强制服务器处理该合并。这似乎工作正常。

这是一颗定时炸弹吗？这是完全可以接受的并且我什么都不担心吗？服务器正在做什么来处理此合并？

Answer 1

Git 使用修订行走来协商双方的一组通用提交。因此，如果在推送期间客户端知道服务器的

master

分支是什么，那么它将能够消除发送其中包含的任何内容，包括旧版本的

local-dev

分支。

正在使用的工作流程对于推送来说不一定效率低下，但是

master

和

local-dev

分支之间重复的纵横交错合并会使

git log --topo-order

very 变慢。因此，虽然对于没有经验的 Git 用户来说这可能不是问题，但它会让高级用户有点不高兴，因为它会导致高级操作变慢。它还创造了一段不整洁的历史，有些人对此有强烈的感受。

此外，此工作流程可防止同时运行多个分支。开发人员可能需要等待合并分支，因为主题专家正在休假，无法进行审核，而创建新分支将允许在等待审核期间处理不同的工作。

典型的工作流程是为有问题的功能或错误修复创建一个新的、唯一命名的分支，进行更改，然后将其推送。当服务器分支合并时，本地分支可以被丢弃（或者如果用户愿意则保留）。

所以最终的答案是，这不是一个典型的工作流程，它会导致一些实际问题，但问题并不大。教育您的用户不是问题，但您是否认为它足够重要并在政策中强制执行取决于您。

Answer 2

简短的回答是不。

建议的方法。

• 应创建一个新分支作为新分支。开发人员必须在该分支上工作
• 拉取请求应通过开发分支或主分支完成。我删除了开发分支并使用主分支创建拉取请求。并且与 master 合并的权限是有限的，因此风险得到了缓解。如果没有选择，我会保留开发分支并使用开发分支创建拉取请求。
• 批准后和发布前从主控创建发布分支，从功能分支到发布分支创建拉取请求，批准，合并。
• 发布发布分支
• 使用主分支和开发（如果有）分支创建拉取请求
• 当产品经理或制作人对发布感到满意时，创建从发布到主控的拉取请求，然后继续你的生活

                     Release branch
                /--------- <- Release ------------ 
master branch  /        /merge with release  \  \  merge feature with master
-----------------------/-----------------------  \
               \ Feat / ure branch                \
                \---------------                   \
                      \  for review purpose only    \
development branch     \   (parallel to master)      \ merge feature with dev
------------------------------------------------------------

抱歉，看起来很乱

Answer 3

如果他们每次选择一些功能时都会对 origin/master 进行变基，那么就没有那么大的危害，因为他们自己的本地开发分支的完整历史记录是与 master 共享的。

但是，如果他们正在做相反的事情，并且实际上正在对 master 进行强制推送并完全重写，那么是的，我会认为他们错误地使用了该工具。如果是这样的话，我想他们也需要一遍又一遍地解决同样的冲突。

变基对于短期功能分支来说并不是有害的，但我可能永远不想在主分支上允许它们（或强制推送），除非是在有人破坏后修复某些东西。