2023 Git 必备知识（三）：小知识推荐配置与小技巧

（本文好像内容较少，我会继续完善。）

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,
  });
}

如果你有不同意见的话，可以到这个问答里讨论。

Tips

GUI 推荐 GitHub Desktop，GitHub 集成很好，其它平台也能用
分支名不要太长，可能导致构建工具失败
依赖变更，翻译更新尽量单独开分支来做，即使跟功能相关的翻译，也要单开分支，这样可以大大减轻 code reviewer 的负担，并且更不容易产生冲突
VS Code 处理冲突比较好用，比 JetBrains 系列 IDE 好用
rebase 时如果 lock 文件产生冲突，可以直接 git checkout --theirs 回退开发分支的修改，rebase 结束后重新安装即可。

总结

至此，我现阶段对 Git 的理解就分享完毕，希望对大家有帮助。未来我收获新知也会继续分享。如果你对 Git 或者版本管理有什么问题或者想法，欢迎留言交流。

2023 Git 必备知识（三）：小知识推荐配置与小技巧

Git 系列文章

“我们有多个客户，交付给每个客户的功能不一样，要维护几个分支？”

推荐配置

`git config --global pull.ff only`

`git config --global core.autocrlf true`

Tips

总结

评论