程序生涯 工作杂谈

写一写面试、工作相关的内容。如果笔者记起来有些有意思的就会更新~

一、merge和rebase的区别

1.merge和rebase后，merge命令不会保留merge的分支的commit：
2.处理冲突的方式：
使用merge命令合并分支，解决完冲突，执行git add .和git commit -m’fix conflict’，这个时候会产生一个commit。
使用rebase命令合并分支，解决完冲突，执行git add .和git rebase --continue，不会产生额外的commit。这样的好处是‘干净’，分支上不会有无意义的解决分支的commit；坏处，如果合并的分支中存在多个commit，需要重复处理多次冲突。
3.git pull和git pull --rebase区别：git pull做了两个操作分别是‘获取’和合并。所以加了rebase就是以rebase的方式进行合并分支，默认为merge。

ps:
工作的公司使用的版本控制相关工具：TortoiseSVN、TortoiseGit、GitExtensions；
代码托管平台：GitLab企业版、Gitee企业版、本地磁盘服务器。

二、消息系统+配置

消息系统+配置，可以构成一套完整的顺流程软件开发体系。因为是配置的关系，可以快速的修改关键参数，调试软件运行的表现情况。
其核心的技术点在于一套通用的消息系统库，加上根据不同业务Task能够顺序执行且足够抽象的执行库。前者完全脱离业务的影响，后者则不然。如果执行库够抽象，那么在不同的开发场景下时，可能存在覆盖缺失的情况；如果执行库不够抽象，它就不够通用，复用程度不高。推荐尽量去抽象执行库，该写的业务胶水代码逃不掉还是得写。

ps：消息系统库：https://blog.csdn.net/itsxwz/article/details/117387193

三、版本控制与团队开发

软件开发是一个团队协作的过程。除非你的功力达到了自己一个人手撸Linux的程度，一般人还是需要和其他的开发共同协作。那么会引申一个问题：很多程序员写的代码怎么整合为一个软件？

我想从亲身经历给大家简单讲一讲。
效力过的公司在解决这个问题上，可以分为两类：
1.谁写的谁一直负责，直到他/她的模块改好了，相关引用方才可以继续后面的流程。这是纯阻塞的做法。
2.划分系统为模块，以2周为一个开发版本节点，开发人员各自负责自己的模块，最后再整合。这是并行的做法。
其实，区分这两种做法的要素很简单。它们都做了版本控制，只是后者是主分支-各个开发分支的模式，而前者仅仅只有一个主分支，大家都在主分支做改动。

ps：开发团队一定不能所有人在一个主分支上进行代码生产，每个人只能在自身的代码分支上进行产出，并保证每一步的提交是正确且没有冲突的，才能合并到主分支。
pps：推荐进行小步提交，这样有问题的时候方便回滚，而不是完成了一大堆的开发事项，一次性的提交。每一次的提交内容要写清楚，而不是简单的一个“1”，这种描述方式神仙也不懂！