慎用协作的分支功能

协作功能中的分支功能较弱，以下场景慎用！！！
如果你的项目需要使用类似gitflow方式进行分支的管理和合并，那么不建议你使用活字格的协作功能！！！
存在问题如下：
活字格最新的update1发布后，看到关于协作的介绍，其中提到可以使用活字格的协作功能实现分支的合并，大感兴趣！
按照gitfolw的方式在新的移动功能开发之前新建了功能分支，修改功能用了修改分支。
先合并了修改分支并发布，因为修改的内容不多，此时还没有发现大问题。
ps：在合并后发现被替换的表中的流程把页面传递的参数都丢失了，需要重新设置

而在合并移动端分支时，因为修改和新增的功能过多，遇到了大问题
活字格当前版本不支持分支合并时的对比分析和提示（在新功能的介绍帖子中有说明，当时没仔细看，就冲动的硬上了），
结果实在是不知道该如何把分支和主干合并。
最后只能用了笨办法了：
步骤1.从gitlab上找到之前修改分支提交的版本，查找具体修改的文件
步骤2.把主干工程导入到移动端分支工程中，导入的内容根据步骤1中获得
步骤3.把移动分支工程重新导入到主干工程中，选择导入所有内容
执行步骤3时，不知道是不是因为项目文件过多，或者活字格设计器有bug，导入了差不多40分钟，结果所有的表都没了，
连管理器中都找不到表了，我感觉我要裂开了！！！

只得强制同步为最新版本（主干）。
然后，发布了移动端分支的工程（步骤2执行后得到的工程）。

总结：
个人感觉，目前协作功能在分支上还不完善，如果场景是从一个主干项目分裂出多个不同的定制化项目，那么可以考虑用分支（其实不用也没啥，项目克隆也能解决这个问题）。如果是类似gitflow的需求，那么大家在使用前，一定要慎重、慎重、再慎重！！！
另外，要变更仓库地址，活字格目前版本的协作功能也是不支持的，而且会导致程序丢失，我之前的一个bug帖子中有说明和官方回复。
所以，协作功能中除了正常的签出、签入操作以外，在做其他改变程序文件的协作操作之前，一定、一定、一定要先另存为一下！！！

大佬，目前和合并的功能，我在新版本发布的直播上说过，建议大家使用导入活字格文件的方式合并

不要直接使用第三方的合并工具合并；

原因：
这个需要对活字格的的原数据做很多的细节处理，工作量特别大；
还有我们后面需要对原数据做一个的解释，不然大家很难知道，哪一行需要合并哪一行不需要合并。这个也比较复杂

Simon.hu 发表于 2022-1-17 15:48
大佬，目前和合并的功能，我在新版本发布的直播上说过，建议大家使用导入活字格文件的方式合并

不要直接 ...

我理解你的意思。
但是，这种做法有个限制，那就是每次改完的东西要尽快合并。
如果长时间不合并，那么就需要通过第三方工具或人工记录变更的内容，以便于导入工程时使用。就好像我遇到的情况，修改分支和移动端分支的发布时间差了一个月，先发布的修改分支一直没有和移动端合并，等到要合并的时候，只能从第三方工具中去找变更的内容了。

beijiait 发表于 2022-1-17 17:00
我理解你的意思。
但是，这种做法有个限制，那就是每次改完的东西要尽快合并。
如果长时间不合并，那么 ...

是的呢，由于第三方工具不好对数据进行细节处理，所以建议您可以将修改中的工程文件另存为，然后通过导入活字格文件的方式来合并。不过没太理解这个和修改完的时间有什么关系呢？为什么必须要从第三方工具中才能找到变更内容呢？