（本文好像内容较少，我会继续完善。）
Git 系列文章
- Git 常用团队规范
- 常见 Git 操作
- Git 推荐配置与小技巧 （本文）
“我们有多个客户，交付给每个客户的功能不一样，要维护几个分支？”
这是一个很常见的问题，也是大家经常出错的地方。比如我之前待过的某厂，给客户交付部署了 a0 版本。然后我们继续开发，搞出来了 bcd 等功能。客户想增加功能，但是不想多付钱；我们收不到钱，又不想得罪客户，于是跟他们协商，只交付 c 功能。于是，负责版本的同学就 cherry-pick c 功能的每次提交，交付给客户。
第一次交付比较顺利，后来就越来越麻烦，交付分支和开发分支的差异越来越大，难以维护。
git 设计用来管理代码的版本，方便我们并行开发、快速迭代。于是它是线性的，基本上是个单向链，我们很难往分支中段插入一个 commit，或者将某个 commit 轻松发布到某几个特定的版本当中。故而，功能模块化和热插拔跟 git 无关，不应该放在一个问题里讨论。
类似的工作，我们需要使用模块化控制，比如构建脚本等。大部分脚手架工具，比如 webpack、vite 都提供有 define 功能，即定义变量，并注入到最终代码。我们可以利用这个功能，配合环境变量，给功能添加开关，然后在编译阶段进行调整，针对不同的用户，输出包含不同功能的代码。
以 Vite 为例，大概是这个样子：
export default defineConfig({
define: {
__CLIENT__: process.env.CLIENT,
},
});const routes = [
// 通用路由
];
// 只有客户是 meathill，才能看到某些路由，配合路由 lazyload，实现打包区分
if (__CLIENT === 'meathill') {
routes.push({
path: '/pay-before-use-feature',
component: () => import('./pay-before-use-feature.vue');
})
} else {
routes.push({
path: '/pay-before-use-feature',
component: SorryYouAreNotAllowed,
});
}如果你有不同意见的话，可以到 这个问答 里讨论。
推荐配置
git config --global pull.ff only
全局配置 git pull 的时候只使用 fast forward only 模式，即只会在采用快进模式，不会将远程分支通过创建 merge commit 的方式合并到本地。可以避免产生多余的 merge commit。
git config --global core.autocrlf true
如果你使用 Windows 系统作为主力开发系统，那最好把自动转换换行符的选项钩上，以便和主要用其它系统的同事一起工作。
Tips
- GUI 推荐 GitHub Desktop，GitHub 集成很好，其它平台也能用
- 分支名不要太长，可能导致构建工具失败
- 依赖变更，翻译更新尽量单独开分支来做，即使跟功能相关的翻译，也要单开分支，这样可以大大减轻 code reviewer 的负担，并且更不容易产生冲突
- VS Code 处理冲突比较好用，比 JetBrains 系列 IDE 好用
- rebase 时如果 lock 文件产生冲突，可以直接
git checkout --theirs回退开发分支的修改，rebase 结束后重新安装即可。
总结
至此，我现阶段对 Git 的理解就分享完毕，希望对大家有帮助。未来我收获新知也会继续分享。如果你对 Git 或者版本管理有什么问题或者想法，欢迎留言交流。
发表回复