跳转至

我的 Git 使用cheat sheet⚓︎

约 1820 个字 53 行代码 预计阅读时间 7 分钟

开发流程

改，发pr，检视，合入main。

一些使用经验和Tips⚓︎

issue相关

提issue，记录开发的新功能等，如果是第12个issue，用 #12 可以直接超链接到对应的issue上。

pr相关

如果是某个merge请求，可通过 ! + 序号的方式超链接到对应的merge上。比如 !12，对应的就是第12个。

一些简单的流程

有新的需求，要开发新的代码，先提issue。然后拉一个新分支，名称就是issue的序号，根据功能不同设置不同前缀。比如：

feature-12 ： 对应第12个issue，开发了一个新的功能；

bugfix-13： 对应第13个issue，修复某个bug；

在分支开发完毕之后，提PR （Pull Request），Code Review之后，合并。

不要一直挂着PR。

Git 当前分支落后主干分支的解决办法

当前的开发分支：feat-one，主线分支：main

  1. 切换到主线分支main：
git checkout main
  1. 拉取远程主线分支main到本地的主线分支main ：
git pull --rebase
  1. 切回到当前的开发分支feat-one：
git checkout feat-one
  1. 拉取远程分支main 的代码：
git rebase main
  1. 将当前开发分支分支feat-one提交到远程分支feat-one：
git push origin feat-one -f

把main分支同步到自己的分支

  1. 创建自己分支：
git checkout -b my-branch
  1. 提交到自己分支
git add .
git commit -m "Commit message"
  1. 一段时间后发现要合并主分支的修改
git checkout main
git pull origin main

（切换到main分支，然后把main分支pull下来）

  1. 切换到自己的分支进行合并操作
git checkout my-branch
git merge master
  1. 如果有冲突，git status 查看冲突的文件
git add conflict-file.txt
git commit -m "Merge changes from master into my-branch"

仓库里的Git文件过大如何解决

git的宗旨是记录下你对这个文件夹的所有操作记录，所以如果不小心把一些很大的pdf或者其他中间文件也放上去的话，git中的object会很大。这不仅要求我们注意仓库的文件大小，也说明必须好好搞gitignore 文件！！

而如果这个情况已经发生了，该怎么减小这个git文件？这就是这里需要解决的事情。准确说你需要一个叫 BFG的清理软件：跳转链接。并且在进行所有操作之前，最好先“暂时关闭分支保护”

然后，并不是完全按照官网操作就可以解决问题了，需要在一开始做一个小小的修改，其他步骤按照操作指南分别操作即可。

前置条件是在电脑上要安装Java虚拟机。这一部分可以自行搜索解决。

按照操作指南 第一步进行操作的时候，要输入：

git clone --mirror git://example.com/some-big-repo.git

这一步是没问题的，但是按照上面的介绍到最后git push 到原来仓库的git文件的时候，如果仓库有关闭的pull request，会提示出错：

To https://github.com/username/repository.git
! [remote rejected]     refs/pull/1/head -> refs/pull/1/head (deny updating a hidden ref)
error: failed to push some refs to 'https://github.com/username/repository.git'

并且在取消分支保护 + 强行合并分支的情况下依然无法解决，后来搜索到的原因见这个链接，里面很清楚地解答了：

The refs beginning 'refs/pull' are synthetic read-only refs created by GitHub - you can't update (and therefore 'clean') them, because they reflect branches that may well actually come from other repositories - ones that submitted pull-requests to you.

解决方案是把上面第一步git clone 语句 替换成：

git clone --bare git://example.com/some-big-repo.git

然后按照BFG的操作手册进行，就完成了！

以我的这个仓库为例，最开始瘦身Git之前，repo 大小（在github 的 setting -> repository 里可以查看）是 238 MB，清除完毕后是73.9MB。效果十分显著。

Github API的一些小技巧

如果想要了解特定Github开源仓库的信息，可以直接从API 获取。具体使用方法如下：

按照链接： https://api.github.com/repos/{这里写你的用户名，不用加括号}/{这里写你的仓库名，不用加括号} 在浏览器访问即可。

比如 https://api.github.com/repos/squidfunk/mkdocs-material 这个链接，就可以直接访问mkdocs materials 作者这个仓库的具体信息。包括仓库大小等具体统计数据。

移动文件的同时保留原文件的git记录⚓︎

  1. 首先，进入git文件夹的目录中：
cd /path/to/myproject
  1. 假定当前路径下，文档目录结构：
.
├── VRP
│   ├── CVRP.ipynb
│   ├── VRPPD.ipynb
│   ├── VRPTW.ipynb
│   └── VRPwithPenality.ipynb
├── assets
│   ├── data
│   └── figures
├── TSP.ipynb
└── requirements.txt

我想要把 TSP.ipynb 文件移动到 VRP 文件夹下。

通过命令：

git mv TSP.ipynb  VRP/

即可。此时观察文件路径，已改变为：

.
├── VRP
│   ├── CVRP.ipynb
│   ├── TSP.ipynb
│   ├── VRPPD.ipynb
│   ├── VRPTW.ipynb
│   └── VRPwithPenality.ipynb
├── assets
│   ├── data
│   └── figures
└── requirements.txt

确认一下。首先执行：

git add .

然后执行：

git status

此时不出意外会看到关于 TSP.ipynb 的修改情况：

On branch basic-dev
Your branch is up to date with 'origin/basic-dev'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        renamed:    TSP.ipynb -> VRP/TSP.ipynb

然后正常commit / push ，即可。

一些规范⚓︎

Git 提交规范（特别是 Angular 规范，这是 Conventional Commits 规范的一个流行实现）中的 feat、fix、chore 以及其他。

这些类型是用来标识每次提交（commit）的主要目的，使得提交历史更加清晰、易于理解，并且可以基于这些类型自动生成更新日志（Changelog）或进行语义化版本控制（Semantic Versioning）。

其中 <type> 就是我们讨论的这些关键字。

feat (feature)
表示新增了一个功能（feature）。当你为代码库添加了一个新的特性时使用。这些提交通常会在版本更新时导致次版本号（minor version）增加（例如从 1.1.0 到 1.2.0），并且会出现在最终用户的更新日志中。
  • feat: add user login functionality
  • feat(api): implement endpoint for fetching user profiles
fix (bug fix)
表示修复了一个 Bug。当你修复了代码中的一个错误时使用。这些提交通常会在版本更新时导致修订号（patch version）增加（例如从 1.1.0 到 1.1.1），并且也会出现在更新日志中。
  • fix: correct calculation error in payment module
  • fix(ui): resolve issue where button was not clickable on mobile
chore (chore / miscellaneous)
表示一些杂项的变动，通常是与构建过程、辅助工具、配置或库的更新等相关，这些变动不直接修改源代码的业务逻辑或用户界面。

用于那些不影响生产代码、用户功能或修复 Bug 的提交。例如：修改 .gitignore 文件、更新依赖库（且不涉及功能改变）、调整构建脚本等。chore 类型的提交通常不会出现在最终用户的更新日志中。

  • chore: update dependencies to latest versions
  • chore(build): adjust webpack configuration for faster builds
  • chore: add linting rule for variable naming
perf (performance):
提升性能的代码更改。 perf: optimize image loading speed by using lazy loading

除了 feat、fix、chore 之外，还有许多其他常用的类型，常见的包括：

  • docs (documentation):

    • 含义：仅仅修改了文档（例如 README、注释、JSDoc 等）。

  • style:

    • 含义：代码格式的修改，不影响代码逻辑（例如空格、格式化、缺少分号等）。

  • refactor:

    • 含义：代码重构，既没有修复 Bug 也没有添加新功能。指那些改进代码结构、可读性或性能，但并未改变其外在行为的修改。
    • 示例: refactor: simplify user authentication logic

  • test:

    • 含义：添加缺失的测试或修正现有的测试。
  • build:
    • 含义：影响构建系统或外部依赖关系的更改（例如 gulp、broccoli、npm、webpack 等）。
    • 示例: build: switch from webpack to esbuild for faster bundling
  • ci (continuous integration):
    • 含义：对 CI 配置文件和脚本的更改（例如 Travis, Circle, BrowserStack, SauceLabs 等）。
    • 示例: ci: fix deployment script for staging environment
  • revert:
    • 含义：撤销之前的某个提交。通常会自动生成，格式类似 revert: feat(auth): add SSO login，并在 body 中说明撤销了哪个 commit hash。