什么是好的Commit
我们总结了3点建议给到大家：
1.Samll
Git库要尽可能地小。尤其是目前的基础设施现状下，虽然你的一个仓库里可以放多个应用，但是维护起来的成本会很大的。还有管理方面，不要在Git上存储构建产物和其他二进制文件。把构建产物放在构建仓库上，虽然给别人方便了，却很难知道这个构建产物是现在的代码产生出来的还是之前产生出来的，这是很难去追溯的。对于二进制文件，如果确有必要（例如游戏的素材），建议使用LFS的方式来保存。
2.Linear
避免无意义的merge，尽量用rebase操作。其次是避免无效commit，有很多代码库commit记录很长，但是里面80%都是无效的，例如都是fix1、fix2这样的commit，都却不知道它具体做了些什么，这种显然是不合理的，对于这种冗长的commit列表，有时候可以在merge的时候squash一下。
3.Atomic
原子性，指操作的原子化。原子性有什么好处呢？一个Commit解决一个特定的问题，比如说我就是修复一个UTcase，或者是加一个UT或者是加一个功能，或者是加一个API，这些明确的问题对应到一个commit，很容易追溯。解决的问题不能很大，不能写了2000行代码解决了一个feature，一起提交，这是非常危险的。作为开发者，做的好的应该是快速有阶段性的成果，并且持续地有反馈，持续地贴近目标。反之，开发者的体验不好，相关协作者的体验也不好，因为别人不知道你做了多少了，很有可能跟你发生mergeconflict。
下面列举一些Commit的反模式：
1.无效的commit
如Mergebranch'develop'of
https://codeup.aliyun.com/abc/xyzintodevelop第一个问题，在几乎所有公司里面都是随便拉开一个代码，本地和远程都有这种情况，本来一个rebase搞定的事情，这样做会导致很多无效的commit，甚至对commit追溯能力会产生很大地影响。
2.巨型commit
一个commit里面包含了大量的代码变化，且属于多个实现目的，就像codereview，有些人提的mergerequest，一下子过来3000多行代码，作为reviewer，你完全不知道他做了什么，这是非常危险的。
3.半成品的commit
如包含有基本语法问题或实现错误的代码的commit半成品的commit。例如，到饭点了，不管了，先提交一把。这样的代码连编译都过不了，这个显然是不好的，没有任何意义。
4.分支间的互相merge
最后一个是分支间的互相merge。从develop合到master，又从master合到develop，互相合来合去，一旦这种合并多了以后，commit就会很难追溯，因为不知道源头在哪。我们建议代码库应该有一个唯一的主干，单向往主干merge，尽量避免反向merge的情况。
（小编推荐：云效代码管理Codeup的主干开发模式，就提倡轻量的commit评审 和主干研发，帮助企业避免分支间的复杂合并～）
软件配置管理
问题：软件配置经常被修改，被发布，它属于代码吗？
软件配置其实是另外一种形式的代码。有可能大家在实际工作中配置不是存在Git仓库里面的，可能是在一个配置中心或者其他类似系统里面，但无论在哪里，本质上，我们可以把配置等同于某种类型的代码。
下图是大家常见的静态配置和动态配置，或者说启动相关的配置和运行相关的配置。
启动相关配置
1. 启动相关配置是构建到镜像中或者作为启动参数传进去的。
2. 启动之后不再修改了，不需要去动态监听它的变化。
3. 对这类配置的修改，一般需要重新创建或者重启容器。
以此类推，哪些配置是启动相关的呢？比如DB连接串、容器CPU规格、启动模式等（比如有的压测应用启动的时候区分master模式和worker模式）。其它像DNS服务地址等，诸如此类的我们都认为是启动相关的配置。
运行相关配置
1. 通常是通过监听某个服务或文件来获取和更新的。比如说我要看一下我的白名单是什么，我去读一下白名单。
2. 配置的更新是不需要修改容器和Pod。
3. 运行中的容器需要持续监听配置的变化，当有变化后自动生效、无需重启。
我们举一下场景实例说明一下：
1. 大促时期调整日志级别，只记录ERROR级别的日志。
2. 服务的黑白名单，为了限制某些IP的访问，将其列入黑名单。
3. 特性开关，通过开关打开或关闭某个feature。
4. 监控采样频率，由每分钟采样一次调整为每5分钟采样一次。
这些配置不需要也不应该每次修改都重新部署应用，他们都属于运行相关的配置。
我们再来看一个demo示例里面哪些是启动相关的，哪些是运行相关的。我们列举一下：
这是启动的时候就会需要的一个参数。
我们将secret文件注入到Deployment中，应用自动从文件感知secret的值，无需重启，因此它是运行时的配置。越内层的配置，修改成本越高。
从另外的角度看一下配置，它有不同的层次，代码、镜像、Pod和系统。代码中的配置位于最内层，修改成本是最高的。因此，如果是编码级别的修改，要经过所有的阶段才能上线。如果运行阶段的话，我是不需要动前面的部分。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
