Git

是什么 一个 Git 仓库（一份 .git 目录）可以同时关联多个"工作树"（working tree），每个工作树是磁盘上一个独立的目录，各自可以检出不同的分支。也就是说不用反复 git checkout 切换分支、不用为了同时看两个分支的代码而 git clone 出第二份仓库。 普通仓库只有一个工作树（主工作树，main worktree）；git worktree 可以在此基础上新增若干"链接工作树"（linked worktree），它们共享同一个 .git 对象库（commit、blob、tree 等），但有各自独立的工作区和索引（index）。 典型场景 紧急修 bug：正在 feature-a 分支开发到一半，不想 stash，直接开一个新工作树检出 main 改 hotfix，改完切回来继续原来的活。 同时对比多个分支的代码，或者在一个分支跑测试的同时在另一个分支继续写代码。 CI / 构建场景：需要同时构建多个分支时，避免重复克隆仓库浪费磁盘和时间。 review 别人的 PR：新建一个工作树检出对方分支，本地起服务验证，不影响自己当前的工作区。 常用命令 # git worktree add <path> [<branch>] # path 是新工作树的目录（不能已存在），branch 是要检出的分支 # 新建一个工作树，并基于新分支 feature-x（自动创建） git worktree add ../feature-x feature-x # 基于已存在的分支创建工作树 git worktree add ../hotfix hotfix-branch # -b <new-branch>：基于 commit-ish（这里是 main）新建分支并检出，一步完成 git worktree add -b hotfix-branch ../hotfix main # 基于某个 commit/tag 创建一个游离状态（detached HEAD）的工作树 git worktree add ../review v1.2.0 # 查看当前仓库关联的所有工作树 git worktree list # 删除一个工作树（目录和 Git 的关联记录一起清理） git worktree remove ../feature-x # 工作树目录被手动删掉了，用这个清理 Git 内部残留的记录 git worktree prune # 防止某个工作树被 prune 误删（比如它在一个可能断线的移动硬盘上） git worktree lock ../feature-x git worktree unlock ../feature-x 注意事项 同一个分支不能同时被两个工作树检出：main 分支已经在主工作树里检出了，就不能在另一个工作树里再检出一次 main，Git 会报错拒绝，这是为了避免同一分支在两处被修改造成冲突。 工作树目录是普通目录，删除前建议先 git worktree remove：直接 rm -rf 目录后，Git 会认为这个工作树"丢了"，需要用 git worktree prune 清理记录，否则 git worktree list 里还会显示一个失效条目。 共享 .git 对象库：多个工作树之间共享 commit 历史和暂存的对象，占用磁盘远小于多次 clone；但每个工作树有独立的索引和 HEAD，互不影响。 链接工作树内部会生成一个 .git 文件（不是目录），内容指向主仓库 .git/worktrees/<name> 下的元数据。 锁定（lock） 锁定是 Git 自带的功能，不是哪个工具额外加的。锁定的工作树会被 Git 保护起来，不会被清理掉、移动或删除。 ...

Git HEAD 当你提交（commit）新更改时，HEAD 会随着分支一起移动到新的提交。 当你切换分支（比如用 git checkout 或 git switch），HEAD 会改变指向，指向你切换到的分支。 这个 HEAD 随你切换分支而变化，始终指向你“当前所在”的分支或 commit。 你在 main 分支，HEAD 内容是 ref: refs/heads/main 你切换到 dev 分支，HEAD 变为 ref: refs/heads/dev 你 checkout 某个历史 commit，HEAD 内容是该 commit 的 SHA（分离 HEAD 状态） # 正常情况下(attached HEAD)，HEAD 是一个符号引用，指向当前分支 # 本地 HEAD 通常指向分支，而不是直接指向提交 cat .git/HEAD # 输出：ref: refs/heads/main # 1. HEAD 指向 main 分支 # 2. main 分支指向它的最新提交 # 3. HEAD 通过分支间接指向最新提交 # HEAD -> 分支 -> 最新提交 # HEAD → refs/heads/main → commit_abc123 # 查看 HEAD 指向的分支 git symbolic-ref HEAD # 输出：refs/heads/main # 查看 HEAD 最终指向的提交 git rev-parse HEAD # 输出：abc123...（提交SHA） git rev-parse HEAD # 获取当前HEAD指向的提交SHA git rev-parse main # 获取main分支的最新提交SHA cat .git/refs/heads/main # 直接查看分支文件内容（提交SHA） detached HEAD # 当检出具体 commit 时，HEAD 直接指向提交 git switch --detach commit_abc123 cat .git/HEAD # 输出：commit_abc123...（直接是提交SHA，不是 ref: 开头） # 此时 HEAD 直接指向提交，不通过分支 HEAD 的作用是告诉 Git “我现在在哪里工作” ...

Git basic commands 目前比较流行的版本管理系统 相比同类软件，Git有很多优点。其中很显著的一点，就是版本的分支 (branch) 和合并 (merge) 十分方便。 有些传统的版本管理软件，分支操作实际上会生成一份现有代码的物理拷贝，而Git只生成一个指向当前版本 (又称"快照") 的指针，因此非常快捷易用。 commands git status --porcelain #用于以简洁、脚本友好的格式显示 Git 仓库当前的状态，方便自动化处理和快速查看文件的变动情况。 git ls-files --unmerged git diff --name-only --diff-filter=U #显示出 HEAD 对应的提交的 hash 值 git rev-parse HEAD git rev-parse --short HEAD # windows install git winget install Git.Git # 显示工作树状态, (已经修改但是没 git add, 或者 没有 git commit) # 显示索引文件和当前HEAD提交有差异的路径，工作树和索引文件有差异的路径，以及工作树中不被Git追踪的路径（也不被gitignore[5]忽略）。前者是你通过运行 "git commit "会提交的东西；第二和第三者是你在运行 "git commit "之前通过运行 "git add "可以提交的东西。 git status -s # 查看本地仓库的当前分支和远程分支的差异(已经 commit 但是还没 push), 展示方式类似 git log git log master ^origin/master # 计算对象数和磁盘消耗 git count-objects -vH # 指定目录 1.8.5 以前 git --git-dir=/Users/jhoffmann/tmp/my-project/.git --work-tree=/Users/jhoffmann/tmp/my-project/ pull # 指定目录 >=1.8.5 git -C /Users/jhoffmann/tmp/my-project/ pull options -C, 大写 C 指定目录, .git 所在的目录 –version, 查看 git 版本 origin https://www.zhihu.com/question/27712995 ...

为什么要用 git clone 默认会把整个历史的所有对象都拉下来。有些场景只需要最新的一份代码，甚至只需要其中一个文件，例如 CI 里构建镜像、流水线里改一行 GitOps manifest 的镜像 tag。这时完整克隆既慢又浪费，网络差的时候还可能超时。 Git 提供了三种互相独立、可以叠加的裁剪方式： 方式 参数 裁掉什么 浅克隆 shallow clone --depth N 历史：只要最近 N 个 commit 部分克隆 partial clone --filter=blob:none 等 文件内容：blob 用到时再按需下载 稀疏检出 sparse checkout --sparse + git sparse-checkout 工作区：只检出指定路径 浅克隆 –depth # only the latest commit git clone --depth 1 https://github.com/foo/bar.git # --depth implies --single-branch; name the branch explicitly git clone --depth 1 --branch main https://github.com/foo/bar.git # by time instead of count git clone --shallow-since=2026-01-01 https://github.com/foo/bar.git --depth 默认带上 --single-branch，只拉一个分支。需要其它分支时，加 --no-single-branch。 ...

先分清两层：Git 和平台 GitHub、Gitea、Forgejo、Codeberg 底层用的都是标准 Git。它们之间的区别不在版本控制，而在包在 Git 外面的那层平台： 版本控制层：Git 负责提交历史、分支、合并，服务器上存的是普通的 Git bare 仓库。本地的 git clone、git push、git pull 在哪个平台上都一样。 平台层：提供 Web 界面、用户和权限、Issue、Pull Request、Wiki、Release、CI 集成等。这些 Git 本身没有，是各平台自己实现的。 另外，这几个名字不是同一类东西： 名字 类型 说明 GitHub 托管服务（闭源） 微软旗下，2018 年被收购 GitLab 平台软件 + 托管服务 有开源社区版，可自建；也有 gitlab.com Gogs 平台软件（开源） Go 编写的轻量 Git 服务，Gitea 的前身 Gitea 平台软件（开源） 2016 年从 Gogs 分叉，可自建 Forgejo 平台软件（开源） 2022 年从 Gitea 分叉，可自建 Codeberg 托管服务（非营利） 运行 Forgejo 的公共实例，codeberg.org 分叉关系：Gogs → Gitea → Forgejo Gogs：早期的 Go 语言自建 Git 服务，单个二进制就能跑，资源占用小。但基本由一位维护者主导，合并社区贡献慢。 Gitea：2016 年社区从 Gogs 分叉出来，采用社区治理，功能迭代快，后来成了自建 Git 服务的主流选择之一。 Forgejo：2022 年 Gitea 的域名和商标被转到新成立的营利公司 Gitea Ltd，部分社区成员担心项目被商业公司控制，于是分叉出 Forgejo。Forgejo 由非营利组织 Codeberg e.V. 托管，一开始是 Gitea 的“软分叉”（持续同步上游），2024 年起变成硬分叉，不再跟随 Gitea 代码。 所以 Gitea 和 Forgejo 目前的界面和用法仍然很像，但功能细节已经开始分化。Forgejo 的一个重点方向是联邦化（ForgeFed 协议），目标是不同实例之间能互相关注、提 Issue、提 PR。 ...

Git graph LR work["Working tree工作树/工作区"] stage["Index / Staging Area暂存区"] repo["Local Repository本地仓库"] remote["Remote Repository远程仓库"] discard["✖ discard丢弃"] work -->|add| stage stage -->|commit| repo repo -->|push| remote remote -->|pull| work remote -->|"fetch/clone"| repo stage -->|checkout| work stage -->|"restore --staged"| work repo -->|merge| work repo -->|"reset --soft"| stage repo -->|rebase| stage repo -->|"reset --mixed"| work repo -->|"reset --hard"| discard 工作区 (working tree) working tree, 2.9.1 之前被称作 Working Directory https://stackoverflow.com/questions/39128500/working-tree-vs-working-directory 也称工作区, 工作目录、工作副本 我们日常开发操作是在工作区中进行的。 工作区的内容会包含提交到暂存区和版本库(当前提交点)的内容，同时也包含自己的修改内容。 索引 (Index, stage, Staging Area) 索引文件也在 .git 目录里 ...

概述 CODEOWNERS 是 GitHub 的一个约定文件：声明仓库里哪些路径由哪些人/团队"负责"。当 PR 改动了某个路径下的文件，GitHub 会自动把对应的 owner 加进 PR 的 Reviewers 列表。配合分支保护规则里的 “Require review from Code Owners”，还可以强制要求这些 owner 必须 approve，PR 才能合并。 它解决的问题：团队变大之后，“这段代码改了应该找谁 review” 不再是靠口头约定或者人肉记忆，而是写进仓库、可版本管理、对所有协作者可见的规则。 文件位置 GitHub 按以下顺序查找，只会使用第一个找到的： 仓库根目录：CODEOWNERS .github/CODEOWNERS docs/CODEOWNERS 文件名区分大小写，没有扩展名，也不支持在多个位置同时生效。 基本语法 语法风格类似 .gitignore：一行一个路径 pattern，后面跟一个或多个 owner。 # 默认 owner，匹配仓库里所有文件 * @wiloon # 某个目录下的文件由指定团队负责 /infra/ @starlabrys/engineering # 具体文件可以指定多个 owner，任意一个 approve 都算数 /docs/architecture.md @wiloon @some-teammate # 用邮箱也可以（必须是该用户在 GitHub 账号上验证过的邮箱） *.sql db-owner@example.com Owner 可以是： @username：单个 GitHub 用户 @org/team-slug：某个组织下的团队 email@example.com：用户在 GitHub 上验证过的邮箱 匹配规则：后面的 pattern 优先级更高 和 .gitignore 不同，.gitignore 靠 ! 取消忽略；CODEOWNERS 没有取消符号，而是文件里越靠后的匹配行优先级越高——如果一个文件同时匹配多条 pattern，以最后一条为准。 ...

.gitignore .gitignore 用来告诉 Git 哪些文件或目录不需要纳入版本控制。 一般在项目开发过程中会产生很多中间文件（例如构建产物、日志、IDE 临时文件），这些文件不适合提交到仓库。通过 .gitignore，可以让 git status 更干净，也能减少误提交。 .gitkeep 则是另一个常见约定：它通常是一个空文件，放在原本为空的目录里用于占位。因为 Git 只跟踪文件，不直接跟踪空目录，所以如果希望目录结构被保留下来（例如 logs/、tmp/），就可以在目录中放一个 .gitkeep 并提交。 常见组合方式： logs/ !logs/.gitkeep 上面的规则表示忽略 logs/ 目录里的运行时文件，但保留 logs/.gitkeep 这个占位文件。 忽略子目录下所有某后缀的文件 **/*.iml 具体使用请看 man gitignore。 在需要的目录下面添加 .gitignore 文件。 文件中每一行表示一个匹配规则（通常可理解为通配模式）。 cat .gitignore .metadata # ignore obj and lib file *.[oa] 当前的目录情况 $ls -al total 24 drwxr-xr-x 4 root root 4096 2010-12-11 12:44 . drwx– 51 root root 4096 2010-12-11 12:44 .. drwxr-xr-x 8 root root 4096 2010-12-11 12:44 .git ...

概述 在参与开源项目开发时，通常的工作流程是：Fork 主仓库 → 在自己的仓库开发 → 保持与主仓库同步 → 提交 Pull Request。本文记录这个完整的操作流程。 前置准备 添加上游仓库 首次 fork 项目后，需要添加原始仓库（上游仓库）作为远程仓库： # 添加上游仓库 git remote add upstream <原始仓库的 git 地址>igin https://github.com/your-username/project.git (fetch) origin https://github.com/your-username/project.git (push) upstream https://github.com/original-owner/project.git (fetch) upstream https://github.com/original-owner/project.git (push) origin: 你的 fork 仓库 upstream: 原始仓库（上游） 保持本地主分支同步 在开发新功能前，或定期需要将上游仓库的最新变更同步到本地： 1. 获取上游仓库的最新变更 git fetch upstream 这会下载上游仓库的所有分支和提交，但不会合并到本地。 2. 切换到本地主分支 git checkout main # 或者 git switch main 3. 检查当前状态 git status 确保工作区是干净的，没有未提交的更改。 4. 合并上游主分支 git merge upstream/main 为什么 main 分支用 merge 而不是 rebase？ ...

概述 给开源项目贡献代码是参与开源社区的重要方式。本文记录了从 Fork 仓库到提交 Pull Request (PR) 的完整流程。 前置准备 Fork 仓库 在 GitHub 上打开你想贡献的开源项目 点击右上角的 Fork 按钮 将仓库 Fork 到你自己的账号下 克隆你的 Fork git clone https://github.com/你的账号/仓库名.git cd 仓库名 配置上游仓库 添加上游仓库（只需做一次） git remote add upstream https://github.com/官方账号/官方仓库.git 验证 remote 配置 git remote -v 输出应该类似： origin https://github.com/你的账号/仓库名.git (fetch) origin https://github.com/你的账号/仓库名.git (push) upstream https://github.com/官方账号/官方仓库.git (fetch) upstream https://github.com/官方账号/官方仓库.git (push) 同步上游代码 在开始新功能开发前，确保你的本地代码与上游保持同步： # 拉取上游最新代码 git fetch upstream # 切换到 main 分支 git checkout main # 合并上游的 main git merge upstream/main # 推送到你的 fork git push origin main 创建功能分支 不要直接在 main 分支上开发，应该创建新的功能分支： ...

Git Stash 比如当前分支是 branch0, 新建了一个文件, 之后发现分支不对, 应该是在 branch1 上添加, 这时就可以用 git stash 暂存当前修改, 切换到 branch1 再 git stash pop. git stash # 如果有新添加的文件，那么就需要添加 -a 参数 git stash save -a "msg0" git stash list git stash pop git stash pop 开启某个修改暂存后，会在 stash list 里面将最近一次的修改暂存记录删除掉，而 git stash apply stash@{0} 则不会。 https://blog.csdn.net/daguanjia11/article/details/73810577 Git Stash用法 最近在使用Git管理项目工程的时候，遇到了很多问题，也学习到了很多关于Git常见使用的技巧，下面就其中关于Git Stash的用法和大家分享下。 首先，简单介绍下Git Stash命令的用法，详细的用法在man文档中有相关介绍，下面我来说明常见的使用。 git stash: 备份当前的工作区的内容，从最近的一次提交中读取相关内容，让工作区保证和上次提交的内容一致。同时，将当前的工作区内容保存到Git栈中。 git stash pop: 从Git栈中读取最近一次保存的内容，恢复工作区的相关内容。由于可能存在多个Stash的内容，所以用栈来管理，pop会从最近的一个stash中读取内容并恢复。 git stash list: 显示Git栈内的所有备份，可以利用这个列表来决定从那个地方恢复。 git stash clear: 清空Git栈。此时使用gitg等图形化工具会发现，原来stash的哪些节点都消失了。 ...

git flow, Git 分支管理, github flow, gitlab flow git flow main: 稳定的生产代码，只有发布版本才合并到这里, 长期分支，始终存在。 develop：日常开发的主分支，所有新功能和 bug 修复先合并到 develop, 长期分支，始终存在。用于整合开发中的代码 feature/xxx：新功能开发的临时分支，开发完成后合并到 develop, 合并之后删掉, 短期分支， 不是长期保持。开发新特性时创建,合并后删除 release/xxx：发布准备分支，从 develop 分出，准备发布, 短期分支， 不是长期保持。 hotfix/xxx：生产环境紧急修复，从 main 分出，修复后合并回 main 和 develop, 短期分支， 不是长期保持。 Git flow 是一个Git分支管理模型，由 Vincent Driessen 于2010年发布在其个人网站的一篇博文中《A successful Git branching model》，该模型适用于多版本管理的项目，能够有效的促进团队成员之间的协作，提升代码的清晰度。 https://nvie.com/posts/a-successful-git-branching-model/ https://www.cnblogs.com/youbins/p/17632165.html Git flow的优点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支。大多数工具都将master当作默认分支，可是开发是在develop分支进行的，这导致经常要切换分支，非常烦人。 更大问题在于，这个模式是基于”版本发布”的，目标是一段时间以后产出一个新版本。但是，很多网站项目是”持续发布”，代码一有变动，就部署一次。这时，master分支和develop分支的差别不大，没必要维护两个长期分支。 github flow 只有主分支（通常是 main 或 master）和临时 feature 分支。 在 GitHub Flow 中并不推荐或保留 develop 分支。 feature/bugfix 分支：开发新功能或修复 bug 时，从 main 分出，开发完成后提 Pull Request（PR），通过代码审查后合并到 main。开发完成后通过 Pull Request 合并到 main，feature 分支随即删除。 GitHub Flow 本身不适合多版本并行维护 https://docs.github.com/en/get-started/using-github/github-flow ...

Install msysgit Choose the Run Git from the Windows Command Prompt option Choose the Use (Tortoise)Plink option Choose the Checkout as-is, commit as-is option

git repo backup git bundle create /tmp/somefile master 然后传输这个文件包， somefile ，给某个其他参与者: 电子邮件，优盘，一个 xxd 打印品和一个OCR扫描仪，通过电话读字节，狼烟，等等。接收者通过键入如下命 令从文件包获取提交: $ git pull somefile 接收者甚至可以在一个空仓库做这个。不考虑大小， somefile 可以包含整个原先 git仓库。 在较大的项目里，可以通过只打包其他仓库缺少的变更消除浪费。例如，假设提交 ‘`1b6d…‘‘是两个参与者共享的最近提交: $ git bundle create somefile HEAD ^1b6d 如果做的频繁，人可能容易忘记刚发了哪个提交。帮助页面建议使用标签解决这个问题。 即，在你发了一个文件包后，键入: $ git tag -f lastbundle HEAD 并创建较新文件包，使用: $ git bundle create newbundle HEAD ^lastbundle http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/zh_cn/ch06.html http://stackoverflow.com/questions/2129214/backup-a-local-git-repository

git 团队协作, Github flow 团队协作中的 Github flow 工作流程 https://zhuanlan.zhihu.com/p/39148914 GitHub flow https://githubflow.github.io/ https://insights.thoughtworks.cn/real-agile-workflow-github-flow/

Repository write access denied Repository write access denied manually add public key to /home/git/.ssh/authorized_keys start with : command=“python /home/www/indefero/scripts/gitserve.py USER”,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa**

gitosis install 用apt-get update 和 apt-get upgrade 更新当前系统. 安装OpenSSH Server: sudo apt-get install openssh-server 修改ssh服务端配置文件/etc/ssh/sshd_config Port 22 # 修改成你想要的登陆端口,如2222 PermitRootLogin no # 禁止root用户登陆 检查密钥的用户和权限是否正确，默认打开的 设置ssh在接收登录请求之前是否检查用户家目录和rhosts文件的权限和所有 权。这通常是必要的，因为新手经常会把自己的目录和文件设成任何人都有写权限。 StrictModes yes RSAAuthentication yes # 启用 RSA 认证 PubkeyAuthentication yes # 启用公钥认证 ServerKeyBits 1024 #将ServerKey强度改为1024比特 PermitEmptyPasswords no # 禁止空密码进行登录 ＃修改完成后，重启ssh服务: sudo /etc/init.d/ssh restart 4.安装git: sudo apt-get install git-core 5.安装gitosis (1)建一个临时文件夹，用来存放下载的gitosis文件，如 mkdir ~/tmp (2)安装gitosis cd ~/tmp git clone git://eagain.net/gitosis git://eagain.net/gitosis.git cd gitosis sudo python setup.py install ...

git diff git diff 查看尚未暂存的文件更新了哪些部分 git diff filename 查看尚未暂存的某个文件更新了哪些 git diff –cached 查看已经暂存起来的文件和上次提交的版本之间的差异 git diff –cached filename 查看已经暂存起来的某个文件和上次提交的版本之间的差异 git diff ffd98b291e0caa6c33575c1ef465eae661ce40c9 b8e7b00c02b95b320f14b625663fdecf2d63e74c 查看某两个版本之间的差异 git diff ffd98b291e0caa6c33575c1ef465eae661ce40c9:filename b8e7b00c02b95b320f14b625663fdecf2d63e74c:filename 查看某两个版本的某个文件之间的差异 显示颜色 ~/.gitconfig 中加三行 [color] status = auto branch = auto ui = auto