我加入了一个新团队，他们的工作方式与我之前习惯的完全不同。以前我们会在一个特性分支上工作，测试人员会在该特性分支上进行测试，然后我们会运行Jenkins作业将该特性合并到develop分支中，待测试通过后会把该分支再次基于develop分支进行变基操作，以使其保持最新。
然后从develop分支中创建一个发行版本，随后发布这个版本并合并到主分支（master）。对于任何人来说，这似乎是一个非常易于理解的工作流程，尤其对于我这样没有经验的Git项目来说。
现在，我在另一个团队中，但没有人真正知道为什么要采用他们当前的工作方式，是否有充分的理由在将develop分支合并到master分支后再将master分支合并回develop分支？
他们的工作流程是这样的：我创建一个功能分支，本地处理该分支，当我对该功能满意后，我会创建一个合并请求（Merge Request）用于合并到develop分支中。然后我会从develop分支中部署我的更改，并进行测试。一旦测试通过，我就会在GitLab上为develop分支上的提交创建一个cherry pick合并到master分支中。当提交成功被合并到master分支后，我将从master分支中发布该更改。
然而，总会有人将master分支再次合并到develop分支中。我向团队的几个成员（这是一个只有5名开发人员的非常小的团队）询问过，但没有人真正知道为什么，他们只是这样做。
之前的项目中，有100多个开发人员在不同的小型开发团队中工作，因此限制要严格得多。
这种工作方式是GitLab特定的吗？