我是一位没有CI / CD管道经验的Android开发人员，我们目前正在使用GitLab进行源代码控制。我正在使用的每个功能（目前是唯一的android开发人员）都在一个单独的分支上进行（分支母版并在另一个分支上进行开发）。我们知道这不是最好的解决方案，但这就是我们现在的工作方式，我们希望对此进行改进。
我们当前遇到的一些问题：
1）如前所述，每个功能当前都位于不同的分支上。当要发布一个版本进行测试/发布时，我们只希望使用一个apk而不是多个apk，并且对于每个apk，我们都需要增加版本号或更改应用程序名称，这从长远来看是不实际的。这个过程如何更充分，更有效？
2）此解决方案也必须与iOS兼容。
有多种可能性，例如Jenkins，Bamboo，Azure管道和GitLab CI。我不确定哪一种将是满足我们需求的更好选择。
谢谢。
答案 0 :(得分：0)
有多种分支策略，也就是git工作流，已经在tine上进行了很好的讨论和测试。.这是一篇有关媒介的文章，详细讨论了它们-https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf
此流程依赖于两个分支
母版-该分支包含生产代码。所有开发代码都会在某个时候合并到主版本中。
开发-此分支包含预生产代码。功能完成后，它们将合并到开发中。
我个人会推荐使用开发分支的策略-因此您的代码将转到功能分支，然后进行开发，然后在开发上标记每个发行版。
每个这样的发行版都会同步到主发行版。您可以在中篇文章中阅读更多内容。
希望这会有所帮助。
答案 1 :(得分：0)
有许多策略可以满足您的需求。这取决于您的团队规模。
每个开发人员都在master分支上工作。他们需要先将fetch和rebase的本地更改推送到master分支的最新提交，然后再将本地更改推送到远程，这意味着push必须是快速转发的推送
在需要发行版本时创建一个release_v1.1.0之类的发行分支。开发人员修复了发行分支上的错误，并且cherry-pick的所有错误修复也都提交给了master分支。
开发人员还可以在测试修订生命周期的发布分支中继续master分支上的新功能。
developer开发人员在自己的分支上工作，并保持变基并将合并的更改合并到develop分支。再次，进行合并时需要快速前进。
使用master分支作为发行分支。从develop分支合并并在发布到产品环境时标记该分支。
也要记住cherry-pick对母版的修复也要开发。
使用GitHub中的内置工作流程。