可以永远使用同一个本地分支吗
Is it OK to use the same local branch forever
我们最近从 Team Foundation 版本控制切换到 git。我在我们的开发团队中发现了一种趋势，即想要从本地 master 创建一个本地分支，将其称为 local-dev，然后永远使用该分支。我们正在使用一个拉取请求过程，因此他们将他们的本地开发推送到服务器上并向主服务器执行一个拉取请求。
当 pull-request 完成后，他们删除了 server-dev 分支但保留了他们的 local-dev 分支。他们只是将最新的拉入本地主控，然后将本地主控合并到本地开发。然后重复这个循环。
这样可以吗？在我的脑海中，我看到由于他们的本地开发人员永远不会重新设置基础，所以他们每次执行拉取请求时都会不断地将所有历史记录从第一天开始推送到服务器上，并强制服务器处理该合并。这似乎工作正常。
这是一颗定时炸弹吗？这是完全可以接受的，我什么都不担心吗？服务器正在做什么来处理此合并？
如果他们每次选择一些功能时都在变基 origin/master，那么就没有那么大的危害，因为他们自己的本地开发分支的完整历史与 master 共享。
但是如果他们做的是相反的，并且实际上是在强制推送 master 和完全重写，那么是的，我会争辩说他们没有正确使用该工具。如果是这样，我想他们也需要一遍又一遍地解决同样的冲突。
Rebases 对短暂的功能分支没有危害，但我可能永远不想在 master 上允许它们（或强制推送），除非它是为了修复某些东西在有人打破它之后。
就我个人而言，当团队成员固步自封并且不愿意尝试（甚至测试）新的工作流程时，这总是令人沮丧。听起来有点有毒的环境。
简短的回答是否。
建议的方法。
- 应创建一个新分支作为新分支。开发人员必须在该分支上工作
- 拉取请求应通过开发或主分支完成。我放弃了开发分支并使用主分支创建拉取请求。与 master 合并的权限是有限的，因此风险得到了降低。如果没有选择，我会保留开发分支并使用开发分支创建拉取请求。
- 批准后和发布前从 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
------------------------------------------------------------
抱歉，看起来很乱
Git 使用修订遍历来协商双方的一组公共提交。因此，如果在推送期间，客户端知道服务器的 master 分支是什么，那么它将能够消除发送它包含的任何内容，包括 local-dev 分支的旧版本。
正在使用的工作流程对于推送来说不一定是低效的，但是 master 和 local-dev 分支之间重复的交叉合并使得 git log --topo-order 非常 慢。因此，虽然对于没有经验的 Git 用户来说这可能不是问题，但它会让高级用户有点不高兴，因为它会导致高级操作有些缓慢。这也造成了一些人强烈反对的不整洁历史。
此外，此工作流可防止同时运行多个分支。开发人员可能需要等待合并分支，因为主题专家正在休假并且无法进行审查，并且创建新分支将允许在等待审查的同时处理不同的工作。
典型的工作流程是为有问题的功能或错误修复创建一个新的、唯一命名的分支，进行更改，然后将其上推。合并服务器分支时可以丢弃本地分支（如果有人愿意，可以保留）。
所以最终的答案是，这不是典型的工作流程，它会导致一些实际问题，但问题不大。教育您的用户不是问题，但您是否认为它足够重要以在政策中强制执行取决于您。
我们最近从 Team Foundation 版本控制切换到 git。我在我们的开发团队中发现了一种趋势，即想要从本地 master 创建一个本地分支，将其称为 local-dev，然后永远使用该分支。我们正在使用一个拉取请求过程，因此他们将他们的本地开发推送到服务器上并向主服务器执行一个拉取请求。
当 pull-request 完成后，他们删除了 server-dev 分支但保留了他们的 local-dev 分支。他们只是将最新的拉入本地主控，然后将本地主控合并到本地开发。然后重复这个循环。
这样可以吗？在我的脑海中，我看到由于他们的本地开发人员永远不会重新设置基础，所以他们每次执行拉取请求时都会不断地将所有历史记录从第一天开始推送到服务器上，并强制服务器处理该合并。这似乎工作正常。
这是一颗定时炸弹吗？这是完全可以接受的，我什么都不担心吗？服务器正在做什么来处理此合并？
如果他们每次选择一些功能时都在变基 origin/master，那么就没有那么大的危害，因为他们自己的本地开发分支的完整历史与 master 共享。
但是如果他们做的是相反的，并且实际上是在强制推送 master 和完全重写，那么是的，我会争辩说他们没有正确使用该工具。如果是这样，我想他们也需要一遍又一遍地解决同样的冲突。
Rebases 对短暂的功能分支没有危害，但我可能永远不想在 master 上允许它们（或强制推送），除非它是为了修复某些东西在有人打破它之后。
就我个人而言，当团队成员固步自封并且不愿意尝试（甚至测试）新的工作流程时，这总是令人沮丧。听起来有点有毒的环境。
简短的回答是否。
建议的方法。
- 应创建一个新分支作为新分支。开发人员必须在该分支上工作
- 拉取请求应通过开发或主分支完成。我放弃了开发分支并使用主分支创建拉取请求。与 master 合并的权限是有限的，因此风险得到了降低。如果没有选择，我会保留开发分支并使用开发分支创建拉取请求。
- 批准后和发布前从 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
------------------------------------------------------------
抱歉，看起来很乱
Git 使用修订遍历来协商双方的一组公共提交。因此，如果在推送期间，客户端知道服务器的 master 分支是什么，那么它将能够消除发送它包含的任何内容，包括 local-dev 分支的旧版本。
正在使用的工作流程对于推送来说不一定是低效的，但是 master 和 local-dev 分支之间重复的交叉合并使得 git log --topo-order 非常 慢。因此，虽然对于没有经验的 Git 用户来说这可能不是问题，但它会让高级用户有点不高兴，因为它会导致高级操作有些缓慢。这也造成了一些人强烈反对的不整洁历史。
此外，此工作流可防止同时运行多个分支。开发人员可能需要等待合并分支，因为主题专家正在休假并且无法进行审查，并且创建新分支将允许在等待审查的同时处理不同的工作。
典型的工作流程是为有问题的功能或错误修复创建一个新的、唯一命名的分支，进行更改，然后将其上推。合并服务器分支时可以丢弃本地分支（如果有人愿意，可以保留）。
所以最终的答案是，这不是典型的工作流程，它会导致一些实际问题，但问题不大。教育您的用户不是问题，但您是否认为它足够重要以在政策中强制执行取决于您。