疾风式全栈(17)-版本控制与开发流程(草稿)

这一次我们来关注一个重要的问题, 代码的管理.

软件项目中最重要和最核心的就是代码. 从形式上看, 代码就是一些某种格式的文本文件. 如果项目大了, 这些文件会很多, 没有一种有效的管理方式的话, 造成的混乱是很可怕的.

除了按照各种语言和框架提供的推荐结构来组织代码, 我们还需要通用的版本控制工具. 帮助我们管理代码的每次修改. 目前主流的版本控制工具是git. 在idea中, 提供了非常方便的git插件.

git的基本操作, 首先是新建仓库. 把需要管理的文件放在一个文件夹下, 在这个文件夹下新建git仓库. 命令行是git init, 仓库建立之后进行首次提交, 把目录下的文件都提交到仓库进行管理.

以后修改文件时, git就会检测到文件进行了修改, 和仓库中保存的状态不一致. 修改完成时, 对修改的文件进行提交, 把新的状态提交到仓库. 每次提交有提交编号和提交记录.

可以在仓库中建立新分支. 比如想要测试一些新的想法, 就可以建立新分支. 新建的仓库默认是有master分支. 建立新分支后签出分支, 在新分支上修改和提交, 不会影响其他分支, 如果测试没结果, 不需要这个分支了, 只需要删除分支, 对于其他分支也不会有任何影响. 这就是git方便的地方.

而idea提供了方便的文件对比和合并功能. 可以清楚的看到文件作了哪些修改.

作为分布式的版本控制系统, git可以在不同的仓库间同步数据. 比如, 我们在github或码云上建立一个空的项目, 把项目地址设置为本地项目的远程地址, 就可以向远程推送代码. 当然需要输入用户名和密码进行授权. 如果其他人要从远程拉取代码, 也是通过远程地址. 大家可以在各自的本地仓库修改和测试, 完成之后推送到远程. 建议在每次推送之前先拉也就是pull, 获取其他人推送的最新代码, 如果有冲突, 在本地先合并, 解决冲突, 再把合并后的代码推送到远程仓库.

关于分支的管理, 小的快速开发的项目, 也可以只有一个分支, 一直在一个分支上提交. 出现问题快速回滚. 所以每次提交不要太多内容. 最好是完成一个小的修改就马上提交. 即使出现问题, 影响也不会太大, 容易恢复. 至于gitflow方式的分支管理, 大家可以自己学习参考. 多数时候选择何种模式是整个团队共同确定的.

git很多时候和代码的测试和发布集成起来, 实现提交后的自动测试和发布. 这也是提高软件开发质量和效率的重要方式. 建议统一使用git管理各个来源的代码.

而docker采用的版本管理思路和git相似. 程序员开发完软件功能后, 再通过docker等容器技术把自己编写的软件发布为服务, 就是DevOps的模式. 与之相对的是传统的模式, 开发人员编写软件, 运维人员负责发布和维护. git和docker等技术提供了流畅的开发和发布体验, 减少了中间反复沟通的环节, 对于提高效率和质量很有帮助.

对于开发规范和工作流程, 需要大家在实际工作中注意整理和总结, 发现问题及时调整. 对于团队开发, 一般会有团队整体的开发流程和规范, 不过在个人的工作工程中, 养成良好的工作习惯也是非常重要的. 软件开发是细致和严谨的工作, 好的工作习惯是重要的支撑, 是优秀程序员的必备品质, 将有助于提升开发的效率和质量. 每天的工作从计划开始, 到总结结束. 并且把任务逐步细分, 每一个小的阶段有明确的目标, 完成功能, 测试通过就马上提交, 写好提交记录. 并且要有对于时间的控制, 任务应该在预估的时间内完成, 如果用时超过可承受的误差范围仍未完成, 就要考虑更换方案或寻求其他解决方式. 开发应该是一直处于清楚可控的状态, 稳步向前推进. 如果发现自己乱了, 不清楚自己在做什么了, 最好马上停下来, 总结现状, 明确目标, 确定解决步骤再继续执行. 最可怕的就是混乱无序, 不仅消耗了大量的时间, 产生的软件也无法让人有信心.

平时还是要多学习, 关注技术动态, 开发思想. 有好的技术和思路可以在自己的工作中逐步引入和尝试, 开始可能用于一些非关键部分, 等熟悉之后可以引入到更多的范围. 每一步都是稳扎稳打, 可以极大的减低引入新技术可能带来的风险.