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

【问题标题】：Is it OK to use the same local branch forever永远使用同一个本地分支可以吗
【发布时间】：2020-05-19 19:11:31
【问题描述】：

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

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

这样做可以吗？在我的脑海中，我看到由于他们的 local-dev 从未被重新定位，因此每次他们执行拉取请求并强制服务器处理该合并时，他们都会不断地将自第 1 天以来的所有历史记录推送到服务器上。这似乎工作正常。

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

【问题讨论】：

In my head I see that since their local-dev is never being rebased 这是您的假设不成立的地方，一旦拉取请求完成，他们将被要求从源站获取，否则他们将与服务器分道扬镳。
他们从 master 合并到他们的 local-dev。但这只是在他们的 local-dev 分支内创建一个新的 commmit-merge 节点，这是我的理解。变基至少会允许历史记录从 master 上的最后一个已知合并开始，但由于他们进行合并，分支历史记录仍保留在第 1 天。不是吗？
哦，那太脏了。如果它有效，则没有真正的问题，但它是错误的。您通常应该为每个新提交到 master 创建新的功能分支。尽可能多地提交工作，如果可以的话，在此过程中进行 rebase。就在 CR 之前，压缩到单个提交，该单个提交将被合并到该功能的 master 中。

标签： git merge rebase pull-request

【解决方案1】：

Git 使用修订遍历来协商双方共同的一组提交。因此，如果在推送期间，客户端知道服务器的 master 分支是什么，那么它将能够消除发送它包含的任何内容，包括旧版本的 local-dev 分支。

所使用的工作流程对于推送来说不一定效率低下，但master 和local-dev 分支之间反复交叉合并会使git log --topo-order 非常变慢。所以虽然这对于没有经验的 Git 用户来说可能不是问题，但它会让高级用户有点不高兴，因为它会导致高级操作的一些缓慢。它还创造了一段不整洁的历史，有些人对此深有感触。

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

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

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

【讨论】：

谢谢。这就是我一直在寻找的。修订行走使得这在技术上不是问题。该团队正在使用 Windows 和 Visual Studio，因此他们还不习惯使用 git log。他们使用 Visual Studio 中内置的工具来查看历史记录。大约四个星期前，我们刚刚过渡。我负责迁移，不知道这种做法是否会导致问题。

【解决方案2】：

简短的回答是否。

建议的方法。

应创建一个新分支作为新分支。开发人员必须在该分支上工作
拉取请求应该使用开发或主分支完成。我放弃了开发分支并使用主分支创建拉取请求。并且与 master 合并的权限是有限的，因此可以减轻风险。如果没有选择，我会保留开发分支并使用开发分支创建拉取请求。
在批准之后和发布之前从 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
------------------------------------------------------------

抱歉，看起来很乱

【讨论】：

【解决方案3】：

如果他们每次选择一些特性时都在重新定位 origin/master，那么不会有太大的危害，因为他们自己的 local-dev 分支的完整历史记录会与 master 共享。

但如果他们反其道而行之，并且实际上是在对 master 进行强制推送和完全重写，那么是的，我会争辩说他们错误地使用了该工具。如果是这样的话，我想他们也需要一遍又一遍地解决同样的冲突。

变基对短命的特性分支没有那有害，但我可能永远不想让它们（或强制推送）在 master 上，除非它是在有人破坏它之后修复某些东西。

就个人而言，当团队成员陷入困境并且不愿意尝试（甚至测试）新的工作流程时，这总是令人沮丧。听起来有点像有毒的环境。

【讨论】：

我的理解是，最好的做法是在成功拉取请求后删除您的本地分支并开始处理新分支。我认为他们不认为 Git 是提交的时间表。他们认为这只会神奇地合并自上次合并以来的最新源更改。
如果您的本地分支是“当前主”的精确副本（使用git reset --hard origin/master），那么它实际上与剪切一个新分支相同。这样做而不是创建一个新分支有点奇怪，但不是非常有害。