上个月脱离了 git，使用了 sftp。
先说一下情况：
1.团队人数比较少，只有 4 个人。并且大家希望在开发的过程中，可以实时看到整体的情况。
2.因为是底层开发的情况，又使用了敏捷开发的模式。虽然我们开发前进行过函数的统一，但每个人的代码都可能随时为适应整体做出一些小改变，进而影响另一个人。我们希望能即使的沟通，并且随时保证函数代码能通用。
3.我们在实际过程中，发现我们统一在公共服务器上实时预览效果能帮助我们更好的了解程序整体。
再说一下，可能为引起各位疑惑的问题。
1.同一文件的反复提交覆盖：因为 ide 自身提供了 merge 的功能，所以这一问题能很好的解决。
2.历史版本：ide 自身提供了历史库，历史也都可以追溯。
3.为什么不用 git：git 的仓库很好很好用。但是对于需要关联密切的底层开发，仓库反复的提交、下载，显得有些累赘。
使用 sftp 管理的心得：
这样处理确实大大加快了开发的进度，得力于良好的沟通，代码也不会出现问题。A 写接口，B 写逻辑，双方完成后提交马上可以看到结果。A 和 B 能根据双方的思路，沟通出更适合的逻辑并写实时的看到结果。
当然这套开发的程序，我也只建议在这一阶段使用。能到实际上线后，我们还是会使用 git 的方式进行版本迭代。
先说一下情况：
1.团队人数比较少，只有 4 个人。并且大家希望在开发的过程中，可以实时看到整体的情况。
2.因为是底层开发的情况，又使用了敏捷开发的模式。虽然我们开发前进行过函数的统一，但每个人的代码都可能随时为适应整体做出一些小改变，进而影响另一个人。我们希望能即使的沟通，并且随时保证函数代码能通用。
3.我们在实际过程中，发现我们统一在公共服务器上实时预览效果能帮助我们更好的了解程序整体。
再说一下，可能为引起各位疑惑的问题。
1.同一文件的反复提交覆盖：因为 ide 自身提供了 merge 的功能，所以这一问题能很好的解决。
2.历史版本：ide 自身提供了历史库，历史也都可以追溯。
3.为什么不用 git：git 的仓库很好很好用。但是对于需要关联密切的底层开发，仓库反复的提交、下载，显得有些累赘。
使用 sftp 管理的心得：
这样处理确实大大加快了开发的进度，得力于良好的沟通，代码也不会出现问题。A 写接口，B 写逻辑，双方完成后提交马上可以看到结果。A 和 B 能根据双方的思路，沟通出更适合的逻辑并写实时的看到结果。
当然这套开发的程序，我也只建议在这一阶段使用。能到实际上线后，我们还是会使用 git 的方式进行版本迭代。
2
Select Language