2023 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 或者版本管理有什么问题或者想法,欢迎留言交流。

如果您觉得文章内容对您有用,不妨支持我创作更多有价值的分享:


已发布

分类

来自

评论

《“2023 Git 必备知识(三):小知识推荐配置与小技巧”》 有 2 条评论

  1. yogwang 的头像

    Aha,被当典型了

  2. […] 2023 Git 必备知识(三):小知识推荐配置与小技巧 […]

欢迎吐槽,共同进步

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据