关于我在公司的一些Git开发经验

河畔一角
1,940 阅读9分钟

前沿

关于Git的文章太多了，很多开发多多少少都会，今天我根据我的日常经验，输出一些软文，尽量不去搬一些常用的Git命令来糊弄大家，把我认为比较重要而且有意义的东西输出给大家，另外对于Git之外的常用的一些技巧也简单整理了一下。

本地推送到远程

一般我们开发的时候，直接克隆远程仓库，这个比较容易，拿到http地址，甩手就是一个git clone http:xxxx完事，但是，如果我们本地已经存在一个项目，想要推送到远程已有的仓库，这个经常遇到，怎么做。

git init
git remote add origin https://github.com/JackySoft/marsview.git
git add .
git commit -m "Initial commit"
git push -u origin master

关键在于需要使用git remote add origin添加一个远程地址。

账号配置

在公司开发项目或者Github推送项目，建议先把个人的git账号配置好，当提交以后，别人可以查到你的提交记录。 同时，如果你的本地邮箱跟Github邮箱不一致，会导致你不会成为Contributor，这个还是非常重要的。 最近有粉丝发现了Marsview的一些问题，于是提交了PR给我，但是最终没有变成Contributor，就是因为本地Git配置有问题。

全局配置

全局配置一般用于公司项目，建议进到公司以后，优先配置个人的公司账号。

git config --global user.name "张三"
git config --global user.email "zhangsan@marsview.cc"

局部配置

局部配置一般用于个人GitHub项目，这个只需要进入到个人项目根目录执行命令即可。

git config user.name "jackysoft"
git config user.email "jackysoft@marsview.cc"

VSCode工具使用

如果你对Git操作命令不熟悉，不妨试试VsCode的Git工具，非常强大，也节约时间。

查看更改记录

image.png

提交代码

image.png

输入修改备注，点击提交即可，提交的时候，如果想要日志更加规范，可以遵循一些习惯。

撤回提交

点击项目右侧三个点，选择commit，点击【撤销上一次提交】即可。

image.png

同样，针对切换分支、合并分支等等都一样，大家去用一下就会了，当然肯定有不少高手不喜欢用工具，这些都是介绍给对命令不熟悉的同学看的，因为不管用什么，效率才是王道。

日志提交规范：

  • feat: 加入新特性
  • fix: 修复bug
  • improvement: 在现有特性上的改进
  • docs: 更改文档
  • style: 修改了代码的格式
  • refactor: 代码重构,不包含 bug 的修复以及新增特性
  • perf: 提升性能的改动
  • test: 测试用例的改动
  • build: 改变了构建系统或者增加了新的依赖
  • ci: 修改了自动化流程的配置文件或者脚本
  • chore: 除了源码目录以及测试用例的其他修改
  • revert: 回退到之前的一个 commit

使用一个好的规范，会让人赏心悦目，建议适当遵循提交规范。

克隆问题

如果你是第一次克隆公司项目，常规来讲，一般用http协议，但是第一次往往需要输入账号密码，第二次就不需要了。如果你不想输入账号密码，可以试试ssh://xxx协议，这种克隆需要在gitlab或者github配置公钥。

一、本地生产密钥

ssh-keygen -t rsa -C "xxx@marsview.cc"

二、复制本地公钥

id_rsa.pub

三、打开Github

image.png

点击右上角点击新建【New SSH Key】，把公钥复制进去即可。

以后通过ssh://xxx克隆项目和推送提交，就不需要账号密码了。

公司分支规范

在公司做项目的过程中，分支规范也很重要，举个例子，团队5个人在同一个项目里面建了5个分支，今晚上线，如果我们上线用release分支，那我们需要把代码都合并进去，但是如果晚上10点，测试发现了问题，无法解决，需要回滚，此时怎么办？

有人可能会说，那就代码也回滚。 的确，代码回滚是一个办法，但是有操作风险，对于不熟悉的人来说，很困难。

也有人会说，发布系统都自带的有回滚功能。的确，借用发布系统的回滚也没问题，但是如果第二天又要Bug需要发布怎么办，release已经被污染了。

根据我的个人经验，为了很好的解决这个问题，我琢磨了一套分支规范：

分支介绍环境
master仓库默认分支，暂不使用-
release线上保护分支PRD
release-pre预发环境分支，用于QA做固定Pre测试Pre
test测试环境分支，用于QA做固定Test测试Test
feature/xxx功能开发分支Dev/Test
hotfix/xxx热修复分支Pre/Prd
release-2024xxx上线分支；上线当日部署到Pre进行验证，通过以后直接作为上线分支使用Pre/Prd

没错，我们每次上线的当天，必须创建一个release-20240816这样的上线分支，其他5个人都把个人feature/xxx合并到上线分支，如果验收无误，第二天直接合并到release即可。 倘若当天上线失败，我们只需要废弃改分支即可，我们可以创建无数个上线分支，这样既不会污染release，又能解决线上回滚问题，一举两得。

代码写一半，需要切换分支怎么办？

大家应该都有这样的经历，我写了一半，突然Leader找我需要修复一个问题发到线上，此时，我相信大部分同学都是直接把本地开发的一堆文件提交到仓库，然后切换分支，等到第二天已经忘了改了什么了，除非你去看commit日志，有没有更好的办法？

答案就是git暂存：git stash

操作命令：

# 缓存本地开发文件
git stash

# 取出最后一条缓存记录并删除
git stash pop

# 查看所有缓存列表

git stash list

# 应用某一条缓存
git stash apply stash@{index}

git stash就是临时保存，等你忙完手里事情以后，在回来，把临时的代码还原，这样可以非常完美的看到刚刚改的代码记录。

拉取方式

代码拉取其实有两种方式，一种是合并拉取，一种是变基拉取，很多人可能对于变基不太了解，然后首次使用的时候，执行git pull命令，可能会给你提示，让你选择拉取方式，我建议对git不熟练的人，选择merge的方式。

所以，进到公司，克隆仓库以后，除了设置个人的git账户，再设置一下拉取方式：

git config pull.rebase false

关闭变基以后，会默认使用代码合并的方式来拉取仓库，什么意思呢？就是假设你本地也有提交，别人也有提交，你需要更新被人的代码，所以要执行git pull，那此时会把你们的代码执行合并操作，这是最保险的，无非是多生产一个提交记录，假设有冲突，你解决冲突也非常容易，因为vscode有冲突对比。

合并分支

如果使用vscode工具的话，直接ctrl shift + P 会弹出菜单，选择merge，然后选择要合并的分支，注意此处是选择要把哪个分支合并到当前分支。

当然有些同学会使用命令，可能觉得命令更快，每个人都有自己的习惯，无可厚非，命令操作：

# 先切换到当前分支
git checkout main

# 合并feature/add分支到本地main分支
git merge feature/add

我个人觉得，使用工具更快，因为如果冲突了，工具会非常直观的把冲突代码拉出来，两边对比，你只需要选择保留或者删除即可。

回滚

回滚一般分为软回滚或者硬回滚，软回滚就是撤回本地提交的代码，你可以做二次修改，然后在强制推送上去。硬回滚就直接把远程代码也撤销了，而且也无法找回，这种就需要慎用。

软回滚

git reset --soft <commit version>

这种方式是最优雅的，撤回以后，代码会暂存在本地，你做二次编辑以后，再次提交上去，但是此时提交的时候，必须使用git push --force强力推上去，因为本地跟远程已经有冲突了。

硬回滚

git reset --hard <commit version>

这种方式比较暴力，如果你拿不定，最好不要用。

当然还有一种方式，就是使用git revert <commit version>，这种方式也是软回滚，只不过会多提交一次记录上去，同时保留以前错误的提交记录，方便你做对比。

题外话

镜像使用

在公司做项目时，我们一般会使用npm或者yarn或者pnpm安装依赖，但是如果你没有科学上网的工具，对于一些境外的插件，可能会安装失败，此时就需要使用镜像。

默认会使用npm官方镜像安装依赖插件，也可以手动设置镜像。

官方默认镜像：

https://registry.npmjs.org

手动指定淘宝镜像：

npm install react --registry=https://registry.npmmirror.com

但是，我不推荐这样的方式，建议在项目根目录创建一个.npmrc文件，用来统一设置镜像。

registry=https://registry.npmmirror.com

创建.npmrc文件，设置镜像后，以后每次安装依赖，都会自动使用该镜像，而且不管你是npm还是yarn还是pnpm都会使用该镜像安装插件。

别名使用

在开发项目的时候，我们会使用import xxx from './../../xxx'这样的路径查找，我们建议尽量给项目设置alias别名，使用import xxx from '@/xxx的方式。

vue.config.js

...
configureWebpack: {  
    resolve: {  
      alias: {  
        '@': path.resolve(__dirname, 'src'),  
        '@components': path.resolve(__dirname, 'src/components'),
      },  
    },  
}
...

vite.config.js

...
resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
    },
}
...

jsconfig 使用

为什么要配置jsconfig.json文件？我们上面已经使用了alias配置了路径别名，但是，我们使用鼠标是无法点进去的，也就是打不开对应的文件，这样的开发体感是非常差的，所以我们需要创建一个jsconfig.json或者tsconfig.json文件。

jsconfig.js

{
  "compilerOptions": {
    "baseUrl": ".",
    "module": "commonjs",
    "paths": {
      "@/*": [
        "./src/*"
      ]
    }
  },
  "vueCompilerOptions":{
    "target": 2
  },
  "checkJs": false,
  "include": [
    "src/**/*"
  ],
  "exclude": [
    "node_modules/**/*"
  ]
}

tsconfig.json

{
  "compilerOptions": {
    "target": "ES2020",
    "useDefineForClassFields": true,
    "lib": ["ES2020", "DOM", "DOM.Iterable"],
    "module": "ESNext",
    "skipLibCheck": true,

    /* Bundler mode */
    "moduleResolution": "Bundler",
    "allowImportingTsExtensions": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react-jsx",
    "baseUrl": "./",
    "paths": {
      "@/*": ["src/*"]
    },

    /* Linting */
    "strict": true,
    "noUnusedLocals": false,
    "noUnusedParameters": false,
    "noFallthroughCasesInSwitch": true
  },
  "include": ["src"],
  "references": [{ "path": "./tsconfig.node.json" }],
  "exclude": ["node_modules", "lib", "es", "dist", "typings", "test", "docs", "tests"]
}

尤其是这段代码：

{
    ...
    "baseUrl": "./",
    "paths": {
      "@/*": ["src/*"]
    }
    ...
}

总结

以上就是我个人在日常工作中，对于Git的一些使用经验，可能不一定适合每个人，只是把我的经验分享给有需要的人，少走一些弯路，另外，我这边关于Git操作命令，有一个非常好的图，献给大家。

Git速查.jpg

avatar
文章
阅读
粉丝