git

Resources

Simple Git tutorial for beginners | Nulab
Learn Git Branching
Pro Git - Git

Reference

git-config

git-branch

重命名当前分支

git branch -m 新分支名称

重命名其他分支

git branch -m 旧分支名称 新分支名称

git-checkout

git checkout <branch_name>
git checkout abc123

git-add

-p 有这么个东西
可以对每个 hunk 交互式选择是否 stage

git-clone

--depth 1 很好用
也可以写成 --depth=1

限制了深度的 clone 叫做浅克隆

浅克隆 (git clone —depth=N) 得到的历史只到某个深度，这导致本地的 master（或其他分支）缺少 older commits。
Git 允许你在此基础上提交并 push，前提是你只基于已有的浅历史产生新提交且远端 tip 仍是你浅克隆时的父提交；否则 push 会失败并提示你需要更多历史。
一旦远端出现你本地没有的旧提交（例如你想基于一个更早的 commit rebase），你需要先运行 git fetch —unshallow 或 git fetch —depth=M 来补齐缺失历史，再进行操作。
如果仓库开启了“接收浅更新”限制（大多数默认允许），无需额外设置；但若服务器禁用了 receive.shallowUpdate，浅仓库 push 会被拒绝，需要管理员解除限制或改用完整克隆。

git-commit

Angular提交信息规范 - Git Guide
如何规范你的Git commit？

因为我在搞 majutsu 的 jjdescription 部分，所以我大概需要对 message 信息有深刻的理解

fixup

How to mask meaningless “fix typo” commit messages | by Daniel Megyesi | Infr…

trailer

git-log

—grep

内置的对 message 的搜索功能

—graph

原来 git 也是有图的输出的

git-grep

在工作树中的已跟踪文件、索引文件中注册的 blobs 或给定树对象中的 blobs 中查找指定的 pattern。
pattern 是由换行符分隔的一个或多个搜索表达式组成的列表。
空字符串作为搜索表达式将匹配所有行。

git-reset

git reset --hard HEAD~1 用来回退一个 commit

git-notes

Git Notes: git’s coolest, most unloved feature - Tyler Cipriani

magit 支持这个功能 Notes (Magit User Manual)

git-remote

添加远程仓库

使用 git remote add 命令：

# 基本语法
git remote add <远程名称> <仓库URL>
 
# 示例
git remote add origin https://github.com/user/repo.git
git remote add origin [email protected]:user/repo.git

或者编辑 .git/config 文件：

[remote "origin"]
    url = https://github.com/user/repo.git
    fetch = +refs/heads/*:refs/remotes/origin/*

常用命令

# 查看现有远程仓库
git remote -v
 
# 修改远程仓库 URL
git remote set-url origin new-url
 
# 删除远程仓库
git remote remove origin
 
# 重命名远程仓库
git remote rename old-name new-name

注意事项：

• 确保 URL 格式正确
• 检查访问权限
• HTTPS 或 SSH 协议选择
• 远程名称通常用 “origin”

验证配置

# 测试连接
git fetch origin
 
# 查看远程分支
git branch -r
 
# 查看详细配置
git remote show origin

git-fetch

遇到了 jujutsu 在 git fetch 的时候给我的警告：

Warning: Ignored refspec `+refs/pull/*/head:refs/pullreqs/*` from `origin`: only refs/heads/ is supported for refspec sources

在这里解释一下
这条 +refs/pull/*/head:refs/pullreqs/* 针对的是 GitHub 暴露的 PR 头引用 refs/pull/<ID>/head，属于 GitHub 的命名约定，并非通用 Git 特性。
(docs.github.com (https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally))

Git 本身不定义 PR 引用，各托管商各用一套：如果远端不是 GitHub，这条 refspec 会抓不到任何东西。

GitLab 的等价路径是 refs/merge-requests/*/head，常见写法：fetch = +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*。
https://docs.gitlab.com/user/project/merge_requests/merge_request_troubleshooting/

Azure DevOps（Azure Repos）通常提供 refs/pull/*/merge（试合并结果）甚至 refs/pull/*/head，对应 refspec 可写成 +refs/pull/*/merge:refs/remotes/origin/pull/*。
https://stackoverflow.com/questions/67715404/git-fetch-pull-requests-from-azure-devops

• 在 refspec 里写成 +<src>:<dst>，前面的 + 表示“允许强制更新”这条映射，不做快进检查。
  • 没有 + 时，如果 <dst> 需要回退（非 fast-forward），git fetch 会拒绝更新该引用并报错。
  • 默认的远端抓取 refspec 就带 +，这样远端即便被强推重写历史，本地的远端追踪分支也会被同步回退。
  • CLI 等价：git fetch origin —force 会对所有 refspec 生效；而前缀 + 是按条目单独生效。
  • 推送时的 refspec 也用同样语法：+master:master 表示只对这一条执行 force-push。

git-push

#更新远程分支：
git push origin 新分支名称
# 删除远程的旧分支：
git push origin --delete 旧分支名称
#设置上游分支：
git push --set-upstream origin 新分支名称

git-pull

git-cherry-pick

git-diff

Git has four main diff algorithms: Myers, Minimal, Patience, and Histogram, with Myers being the default.

Patch

补丁就是用 diff 生成出来的

所以 jj-diff 无法提供这样可以 apply 的 patch 吗？

Algorithms

• Myers

  默认算法，它找出最长公共子序列，并将更改分类为添加或删除。
  The Myers diff algorithm: part 1 – The If Works

• Minimal

  Myers 算法的改进版本，它尝试生成尽可能小的 diff，即使计算时间更长。

• Patience

  一种更高级的算法，可以产生比 Myers 更易读的差异比较结果。

• Histogram

  耐心算法的扩展，尝试识别频繁出现的常见行并降低其优先级，对于某些类型的更改，可以产生更易读的差异比较结果。

git-apply

Apply a patch to files and/or to the index

git-rebase

git-revert

git-fsck

git-format-patch

要是哪天我能用上这东西我也就出息了

git-hook

Git hooks 是在特定 Git 事件发生时自动执行的脚本，位于 .git/hooks/ 目录。

客户端 hooks

• pre-commit

  提交前执行，用于代码检查、格式化等。退出非零值会中止提交。

• prepare-commit-msg

  在编辑器打开前修改提交信息模板。

• commit-msg

  检查提交信息格式，常用于强制提交信息规范。

• post-commit

  提交完成后执行，用于通知或日志记录。

• pre-push

  推送前执行，可用于运行测试或检查。

服务端 hooks

• pre-receive

  接收推送前执行，可拒绝整个推送。

• update

  对每个分支执行，可单独拒绝某个分支的更新。

• post-receive

  推送完成后执行，常用于部署、通知等。

使用方法

# hooks 位于
.git/hooks/
 
# 创建 hook（去掉 .sample 后缀）
mv .git/hooks/pre-commit.sample .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit

注意事项

• hooks 不会被 git 跟踪，需要手动分发或使用工具管理
• 可以用 core.hooksPath 配置自定义 hooks 目录
• 常用工具：husky、pre-commit 等

git-submodule

Resources

Working with submodules - The GitHub Blog
Git - Submodules

git extensions

git-lfs

Git Large File Storage | Git Large File Storage (LFS) replaces large files su…

Learning About Git Large File System (LFS) | by Amy Li | The Startup | Medium

Managing large files - GitHub Docs

lfs-s3

把大文件托管到代码托管平台貌似不是一件便利的事情
但是我们可以用自己配置的存储后端！

这个项目是最新的项目，而且实现方式貌似更加简单

Introduction chat

下面是关于 Git LFS（Git Large File Storage）的详尽介绍，帮助你了解它的原理、使用场景、安装配置及常用命令等。

1. 什么是 Git LFS

   • Git LFS 是 Git 的一个扩展，用于在版本库中管理大体积文件（如音视频、二进制资源、数据集等）。
   • 它将大文件本身存储在专门的存储服务器（LFS Server）上，而在 Git 仓库里只保留一个指向这些大文件的“指针”文件，从而避免 Git 仓库体积暴涨。

2. 为什么需要 Git LFS

   • 传统 Git 会把所有文件都完整存入 .git 目录，导致仓库体积随大文件增加而迅速膨胀。
   • 克隆、拉取、推送都会变得很慢，也不容易回滚到历史版本。
   • Git LFS 可显著减小仓库大小，加快 Git 操作。

3. Git LFS 的工作原理
   1）在本地提交大文件时：

   • Git LFS 钩子（pre-push 或 clean filter）会拦截符合规则的大文件，替换为一个小型的指针文件（包含文件 ID、大小、下载地址等元信息）。

   2）推送到远程时：

   • 指针文件随 Git 普通流程推到 Git 服务器。
   • 大文件内容则通过 LFS 协议上传到 LFS 服务器（可以是 GitHub/GitLab 内置的 LFS 服务，也可以自行部署）。

   3）克隆或检出时：

   • Git 拉取指针文件后，Git LFS 会自动（或按需）下载实际的文件内容到工作区。

4. 安装与初始化
   1）安装

   • macOS（Homebrew）：
     brew install git-lfs
   • Windows（Chocolatey 或官方安装包）：
     choco install git-lfs
   • Linux（包管理器或二进制包）：
     apt-get install git-lfs
     或下载并解压官方 Release。

   2）配置全局钩子
   执行一次：
   git lfs install
   该命令会在 ~/.gitconfig 或仓库 .git/config 中添加相应的 filter 钩子。

5. 常用命令
   1）指定跟踪某类文件
   git lfs track “.psd”
   git lfs track “data/.zip”
   该命令会在仓库根目录生成或更新 .gitattributes 文件。
   2）查看跟踪规则
   git lfs track
   3）移除跟踪
   git lfs untrack “*.psd”
   4）添加、提交、推送同普通 Git
   git add .gitattributes
   git add path/to/large.file
   git commit -m “add large file”
   git push
   5）查看 LFS 状态
   git lfs status
   6）列出已上传的大文件引用
   git lfs ls-files
   7）下载/拉取 LFS 文件

   • 在 clone 后自动下载（默认行为）。
   • 或者手动执行：
     git lfs pull
     git lfs fetch —all

6. 与远程仓库的配合

   • GitHub、GitLab、Bitbucket 等平台都对 Git LFS 提供官方支持，你只需在仓库中开启 LFS 功能即可。
   • 免费额度和计费：
     这些平台通常对 LFS 存储和带宽有免费额度，超过后可能需要付费。
   • 私有部署：
     可结合开源项目（如 Git LFS Server、Minio 等）搭建自建 LFS 服务。

7. 注意事项

   • .gitattributes 文件要纳入版本控制，确保团队成员都使用相同的跟踪规则。
   • LFS 对历史大文件的清理需要配合工具（如 git lfs prune、git gc 或 BFG Repo-Cleaner 等）。
   • 在切换分支、执行 git checkout 时，LFS 会自动下载对应版本的大文件，可能造成网络请求或延迟。
   • 避免频繁修改同一个大文件，否则 LFS 存储也会不断累积多份历史版本。

8. 常见问题

   • “LFS objects missing from server”
     请检查远程 LFS 服务是否启用、访问凭据是否正确。
   • 带宽/存储超限
     评估团队使用场景，必要时升级配额或自建存储。
   • 大文件未被正确追踪
     确认 .gitattributes 规则匹配到文件，并重新 git add 后提交。

9. 参考资源

   • 官方文档：https://git-lfs.github.com/
   • GitHub LFS 指南：https://docs.github.com/en/repositories/working-with-files/managing-large-files/
   • GitLab LFS 教程：https://docs.gitlab.com/ee/topics/git/lfs/

通过以上介绍，你应该对 Git LFS 的动机、原理、使用方法与注意事项有了全面的了解。开始使用时，可先在测试仓库里试验一遍，熟悉工作流后再在正式项目中推广。

git-flow

Using git-flow to automate your git branching workflow

gitflow-avh

GitHub - nvie/gitflow: Git extensions to provide high-level repository operat…

gitflow-cjs

AUR (en) - gitflow-cjs
GitHub - CJ-Systems/gitflow-cjs: CJS Edition of the git extensions to provide…

avh 版本已经不再维护了，现在这个是主流版本

为什么 GitFlow”失宠”了？

CI/CD 兴起：持续部署让复杂分支变得不必要
敏捷开发：快速迭代不需要复杂流程
小团队增多：独立开发者和小团队更喜欢简单方案
云服务普及：部署成本降低，可以更频繁发布

git-filter-repo

Products providing Git hosting

github
sourcehut
gitea
gitlab
Codeberg
Gitee