Git实战宝典:从翻车现场到绝地求生

Git实战宝典:从翻车现场到绝地求生

学了前四期,你已经掌握了Git的理论和最佳实践。但现实世界不是童话,翻车才是常态。

这一期,我们直面那些让新手崩溃、让老手头秃的真实场景。每个问题都有救,只要你知道正确的方法。

紧急救援手册

场景1:commit后发现写错了

情况A:还没push

# 修改最后一次提交
git commit --amend -m "正确的提交信息"

# 或者补充文件
git add forgotten-file.txt
git commit --amend --no-edit

情况B:已经push了

# 如果只有你在这个分支工作
git commit --amend -m "正确的提交信息"
git push --force-with-lease

# 如果有别人也在用这个分支,不要用amend!
# 而是创建新的修复提交
git revert HEAD
git push

场景2:提交到错误的分支

# 你在main分支提交了,但应该在feature分支

# 1. 撤销当前提交,保留改动
git reset HEAD~1 --soft

# 2. 切换到正确的分支
git checkout feature-branch

# 3. 重新提交
git commit -m "feat: xxx"

场景3:需要撤回多个提交

# 撤回最近3个提交,保留改动在工作区
git reset HEAD~3

# 撤回最近3个提交,保留改动在暂存区
git reset HEAD~3 --soft

# 撤回最近3个提交,丢弃所有改动(危险!)
git reset HEAD~3 --hard

场景4:误删分支

# 查找被删分支的最后一个提交
git reflog

# 找到类似这样的记录
# abc1234 HEAD@{5}: checkout: moving from feature-xxx to main

# 重建分支
git checkout -b feature-xxx abc1234

场景5:误删文件

# 删除了工作区文件,想恢复
git checkout -- deleted-file.txt
# 或
git restore deleted-file.txt

# 删除了文件并已提交
git checkout HEAD~1 -- deleted-file.txt
git commit -m "restore: 恢复误删文件"

场景6:需要撤销已push的提交

# 方法1:revert(推荐,不改写历史)
git revert 
git push

# 方法2:reset + force push(危险,仅限个人分支)
git reset --hard 
git push --force-with-lease

revert创建一个新提交来撤销改动,不改写历史,适合已push的提交。reset回退指针,会改写历史。

场景7:merge出错想重来

# 合并过程中发现冲突太多,想放弃
git merge --abort

# 已经合并完成但想撤销
git reset --hard HEAD~1

场景8:需要合并特定的几个提交

# 方法1:cherry-pick
git cherry-pick   

# 方法2:交互式rebase
git rebase -i 
# 在编辑器中把不需要的提交标记为drop

历史改写

修改历史提交信息

# 修改最近3个提交的信息
git rebase -i HEAD~3

# 把要修改的提交前面的pick改成reword
# 保存后Git会逐个让你编辑提交信息

合并历史提交

git rebase -i HEAD~3

# 把后面几个提交的pick改成squash
# 保存后编辑合并后的提交信息

删除历史提交

git rebase -i HEAD~5

# 把要删除的提交改成drop

从历史中删除敏感文件

# 使用BFG Repo-Cleaner(快)
bfg --delete-files secrets.yml
git reflog expire --expire=now --all
git gc --prune=now --aggressive
git push --force

# 使用git filter-repo(现代推荐)
pip install git-filter-repo
git filter-repo --path secrets.yml --invert-paths

# 使用git filter-branch(慢,已废弃)
git filter-branch --force --index-filter \
  'git rm --cached --ignore-unmatch secrets.yml' \
  --prune-empty --tag-name-filter cat -- --all

重要:改写历史后通知所有协作者重新clone!

大文件处理

问题:仓库太大

# 查看哪些文件占用空间
git rev-list --objects --all | \
  git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | \
  sed -n 's/^blob //p' | \
  sort --numeric-sort --key=2 | \
  tail -20

解决方案1:Git LFS

# 安装Git LFS
brew install git-lfs  # Mac
apt install git-lfs   # Ubuntu

# 初始化
git lfs install

# 跟踪大文件
git lfs track "*.psd"
git lfs track "*.zip"
git lfs track "assets/**"

# 查看跟踪规则
git lfs track

# 提交跟踪规则
git add .gitattributes
git commit -m "chore: 配置Git LFS"

解决方案2:清理历史

# 从历史中彻底删除大文件
git filter-repo --path huge-file.zip --invert-paths

# 清理垃圾
git reflog expire --expire=now --all
git gc --prune=now --aggressive

性能优化

clone太慢

# 浅克隆(只克隆最近的历史)
git clone --depth 1 https://github.com/user/repo.git

# 单分支克隆
git clone --single-branch --branch main https://github.com/user/repo.git

# 后续获取完整历史
git fetch --unshallow

仓库太大

# 清理无用对象
git gc

# 更激进的清理
git gc --aggressive --prune=now

# 清理reflog
git reflog expire --expire=now --all
git gc --prune=now

status太慢

# 禁用文件监控(大仓库)
git config core.fsmonitor false
git config core.untrackedCache false

子模块

添加子模块

git submodule add https://github.com/user/lib.git libs/lib

克隆包含子模块的仓库

# 方法1:克隆时自动初始化
git clone --recursive https://github.com/user/repo.git

# 方法2:克隆后手动初始化
git clone https://github.com/user/repo.git
cd repo
git submodule init
git submodule update

更新子模块

# 更新到最新
git submodule update --remote

# 更新所有子模块
git submodule foreach git pull origin main

删除子模块

# 删除子模块(Git 1.8.3+)
git submodule deinit libs/lib
git rm libs/lib
rm -rf .git/modules/libs/lib

常见错误

error: Your local changes would be overwritten

# 情况1:想保留本地修改
git stash
git pull
git stash pop

# 情况2:丢弃本地修改
git reset --hard
git pull

fatal: refusing to merge unrelated histories

# 两个仓库历史不相关,需要强制合并
git pull origin main --allow-unrelated-histories

! [rejected] main -> main (non-fast-forward)

# 远程有新提交,先拉取
git pull --rebase origin main
git push origin main

fatal: Authentication failed

# 检查SSH密钥
ssh -T git@github.com

# 检查远程URL
git remote -v

# 切换到SSH
git remote set-url origin git@github.com:user/repo.git

# 或使用token
git remote set-url origin https://@github.com/user/repo.git

fatal: not a git repository

# 当前目录不在Git仓库中
# 初始化仓库
git init

# 或进入正确的目录
cd /path/to/repo

调试技巧

查看某行代码的修改历史

# 查看文件的每一行是谁在什么时候改的
git blame filename.txt

# 只看某几行
git blame -L 10,20 filename.txt

# 查看某行代码的完整历史
git log -p -S "特定代码" filename.txt

找出引入bug的提交

# 二分查找
git bisect start
git bisect bad          # 当前版本有bug
git bisect good v1.0    # v1.0版本正常
# Git会自动跳到中间提交,你测试后标记
git bisect good/bad
# 重复直到找到
git bisect reset

查看reflog(操作日志)

# 查看所有操作记录
git reflog

# 找到误删的提交
git checkout 

最佳实践总结

DO

  1. 频繁提交:小步快跑,每个逻辑改动一个提交
  2. 写好提交信息:让未来的自己和队友能看懂
  3. 先pull再push:避免不必要的冲突
  4. 使用分支:不要在main上直接开发
  5. 定期备份:重要分支推送到远程

DON'T

  1. 不要push --force:除非你确定自己在做什么
  2. 不要commit敏感信息:密码、密钥一旦push就很难彻底清除
  3. 不要在公共分支rebase:会改写历史,坑队友
  4. 不要忽略.gitignore:node_modules、.env必须忽略
  5. 不要提交大文件:使用Git LFS

Git速查表

# 初始化
git init                          # 初始化仓库
git clone                    # 克隆仓库

# 日常操作
git status                        # 查看状态
git add                     # 添加到暂存区
git commit -m "message"           # 提交
git push                          # 推送
git pull                          # 拉取

# 分支操作
git branch                  # 创建分支
git checkout              # 切换分支
git checkout -b           # 创建并切换
git merge                 # 合并分支
git branch -d             # 删除分支

# 撤销操作
git checkout --             # 撤销工作区修改
git reset HEAD              # 撤销暂存
git commit --amend                # 修改最后一次提交
git revert                # 撤销提交(安全)
git reset --hard          # 回退到指定提交(危险)

# 历史查看
git log --oneline --graph         # 图形化日志
git blame                   # 查看每行修改记录
git reflog                        # 操作历史

# 暂存工作
git stash                         # 暂存当前工作
git stash pop                     # 恢复暂存

系列总结

恭喜你完成了整个Git系列!

第一期:Git基础 - 从安装到日常操作
第二期:分支管理 - 在平行宇宙中开发
第三期:团队协作 - Pull Request与代码审查
第四期:自动化 - 钩子、CI/CD与效率工具
第五期:实战宝典 - 从翻车到救命

你现在已经是Git高手了。但记住:Git只是工具,真正重要的是团队协作的规范和习惯。工具再好,用不好也是白搭。

保持学习,保持实践,保持分享。Git的世界还有很多宝藏等你探索。


进阶资源


恭喜!你已经掌握了Git的全部核心技能。去征服代码世界吧!

Views: 51

Git钩子与自动化:让代码质量自动守护

Git钩子与自动化:让代码质量自动守护

前三期我们掌握了Git的基础操作、分支管理和团队协作。现在,让我们把效率提升到下一个层次——自动化。

Git钩子(Hooks)是Git在特定事件发生时自动执行的脚本。比如,每次commit前自动检查代码格式,每次push前自动运行测试,每次merge后自动部署。

这一期,我们深入Git的自动化世界。

Git钩子基础

钩子存放在.git/hooks/目录:

ls -la .git/hooks/

你会看到很多.sample文件,这是示例。去掉.sample后缀就激活了。

钩子类型

客户端钩子(本地执行):

  • pre-commit:commit前,检查代码
  • prepare-commit-msg:commit message生成后,编辑器启动前
  • commit-msg:commit message写完后,检查格式
  • post-commit:commit完成后,发通知
  • pre-push:push前,跑测试
  • post-checkout:切换分支后,安装依赖

服务端钩子(远程执行):

  • pre-receive:push到达服务器时
  • update:每个分支更新时
  • post-receive:push完成后

第一个钩子

创建一个简单的pre-commit钩子,检查是否有console.log

# .git/hooks/pre-commit
#!/bin/bash

# 检查暂存区的JS文件
files=$(git diff --cached --name-only --filter=ACM | grep '\.js$')

if [ -z "$files" ]; then
    exit 0
fi

# 检查是否有console.log
if grep -n "console\.log" $files; then
    echo "❌ 发现console.log,请移除后再提交"
    exit 1
fi

exit 0
chmod +x .git/hooks/pre-commit

现在,如果有console.log,commit会被拒绝。

Husky:现代钩子管理

直接编辑.git/hooks/有几个问题:

  • 钩子不会被Git跟踪,队友无法共享
  • 每次clone后需要手动设置
  • 脚本管理混乱

Husky解决了这些问题。

安装

npm install husky --save-dev

# 初始化(自动创建.husky目录)
npx husky init

配置pre-commit

# 创建pre-commit钩子
echo "npm test" > .husky/pre-commit

现在每次commit前会自动运行测试。测试失败,commit就被拒绝。

配置commit-msg

验证提交信息格式:

# .husky/commit-msg
#!/bin/bash

msg=$(cat $1)

# 检查是否符合约定式提交
if ! echo "$msg" | grep -qE "^(feat|fix|docs|style|refactor|test|chore)(\(.+\))?: .{1,}"; then
    echo "❌ 提交信息格式错误"
    echo "格式: (): "
    echo "示例: feat(auth): 添加OAuth登录"
    exit 1
fi
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit "$1"'

lint-staged:只检查暂存文件

全量检查太慢?lint-staged只检查你改动的文件。

npm install lint-staged --save-dev
// package.json
{
  "lint-staged": {
    "*.js": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.css": [
      "stylelint --fix",
      "prettier --write"
    ],
    "*.{json,md}": [
      "prettier --write"
    ]
  }
}
# .husky/pre-commit
npx lint-staged

流程:

  1. git commit触发pre-commit
  2. lint-staged检查暂存的文件
  3. ESLint/Prettier自动修复
  4. 修复后的文件重新add
  5. commit继续

commitlint:提交信息规范

npm install @commitlint/cli @commitlint/config-conventional --save-dev
// commitlint.config.js
module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [
      2,
      'always',
      [
        'feat',
        'fix',
        'docs',
        'style',
        'refactor',
        'perf',
        'test',
        'build',
        'ci',
        'chore',
        'revert'
      ]
    ],
    'subject-case': [2, 'always', 'lower-case']  // 主题小写
  }
};

现在,不符合规范的提交会被拒绝:

git commit -m "添加功能"
# ❌ 提交失败:必须以type开头

git commit -m "feat: 添加用户登录功能"
# ✅ 提交成功

完整工作流配置

一个现代化的前端项目配置:

// package.json
{
  "scripts": {
    "prepare": "husky install",
    "lint": "eslint . --ext .js,.ts,.tsx",
    "format": "prettier --write .",
    "test": "jest"
  },
  "lint-staged": {
    "*.{js,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{css,scss,json,md}": [
      "prettier --write"
    ]
  },
  "devDependencies": {
    "@commitlint/cli": "^18.0.0",
    "@commitlint/config-conventional": "^18.0.0",
    "eslint": "^8.0.0",
    "husky": "^9.0.0",
    "lint-staged": "^15.0.0",
    "prettier": "^3.0.0"
  }
}
# .husky/pre-commit
npx lint-staged

# .husky/commit-msg
npx --no -- commitlint --edit $1

# .husky/pre-push
npm test
// commitlint.config.js
module.exports = { extends: ['@commitlint/config-conventional'] };

一次clone后,所有开发者都会自动拥有相同的检查规则。

Git别名:效率提升

配置常用别名,减少输入:

# 基础别名
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit

# 查看日志
git config --global alias.lg "log --oneline --graph --all"
git config --global alias.last 'log -1 HEAD'

# 撤销
git config --global alias.unstage 'reset HEAD --'
git config --global alias.undo 'checkout HEAD --'

# 有用的别名
git config --global alias.stash-all 'stash save --include-untracked'
git config --global alias.push-force 'push --force-with-lease'

使用:

git st          # = git status
git lg          # 美观的日志图
git unstage file.txt  # 取消暂存

自定义Git命令

创建git-xxx脚本,就能用git xxx调用:

# ~/bin/git-publish
#!/bin/bash
# 发布当前分支到远程

branch=$(git branch --show-current)
git push -u origin $branch
chmod +x ~/bin/git-publish
export PATH=$PATH:~/bin

# 使用
git publish

自动部署

post-receive钩子(服务端)

在服务器上配置自动部署:

# /var/git/project.git/hooks/post-receive
#!/bin/bash

TARGET="/var/www/project"
GIT_DIR="/var/git/project.git"

while read oldrev newrev ref
do
    BRANCH=$(git rev-parse --symbolic --abbrev-ref $ref)

    if [ "$BRANCH" = "main" ]; then
        echo "Deploying main branch..."
        git --work-tree=$TARGET --git-dir=$GIT_DIR checkout -f main
        cd $TARGET
        npm install --production
        pm2 restart project
        echo "Deploy complete."
    fi
done

现在,push到main分支会自动部署。

GitHub Actions自动部署

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci
      - run: npm run build

      - name: Deploy to server
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USERNAME }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            cd /var/www/project
            git pull
            npm ci --production
            pm2 restart project

Vercel/Netlify自动部署

最简单的方式:连接GitHub仓库,自动部署。

  • push到main → 自动构建 → 自动部署
  • PR预览 → 每个PR都有独立预览链接
  • 回滚 → 点一下就回退

Git bisect:定位问题提交

当项目出现bug,但不知道是哪个提交引入的:

# 开始二分查找
git bisect start

# 标记当前提交有问题
git bisect bad

# 标记某个旧提交是正常的
git bisect good v1.0.0

# Git会自动跳到中间的提交
# 你测试后标记
git bisect good  # 或 git bisect bad

# 重复直到找到问题提交
# Git会告诉你哪个提交有问题

# 结束
git bisect reset

自动化:

# 自动运行测试脚本来判断
git bisect run npm test

Git worktree:多分支并行开发

需要同时在多个分支工作,但不想频繁切换?

# 创建worktree
git worktree add ../project-feature feature-branch

# 现在有两个工作目录
# ../project (main分支)
# ../project-feature (feature-branch)

# 在project-feature中工作
cd ../project-feature
# 修改、提交...

# 完成后删除worktree
git worktree remove ../project-feature

小结

你现在掌握了Git自动化的核心技能:

  • Git钩子原理和常用钩子
  • Husky + lint-staged + commitlint现代工作流
  • 配置Git别名提升效率
  • 服务端自动部署
  • GitHub Actions CI/CD
  • Git bisect定位问题
  • Git worktree多分支并行

下一期,我们将进入实战环节——常见坑与解决方案。你会学到如何处理那些让新手崩溃的场景。


练习任务

  1. 为你的项目配置Husky + lint-staged
  2. 配置commitlint,尝试提交不规范信息(应该被拒绝)
  3. 配置一个Git别名,一键查看美化日志
  4. 用git bisect找一个故意引入的bug

下期预告:《Git实战:常见坑与解决方案》—— 误删分支怎么办?提交到错误分支怎么救?大文件怎么处理?

Views: 19

Git团队协作:让代码审查成为日常

Git团队协作:让代码审查成为日常

前两期我们掌握了Git的基础操作和分支管理。但Git的真正威力在于协作——让一群人同时开发,而不会互相踩脚。

这一期,我们来聊聊团队协作的最佳实践。

Fork vs Clone

Clone:直接克隆仓库,有写权限

git clone git@github.com:myteam/project.git

适用于团队成员,对仓库有直接写权限。

Fork:在你的账号下创建仓库副本

  1. 在GitHub/GitLab页面点击Fork
  2. 克隆你fork的仓库
    git clone git@github.com:yourname/project.git

    适用于开源贡献者,对原仓库没有写权限。

Pull Request工作流

Pull Request(PR)是GitHub的叫法,GitLab叫Merge Request(MR)。本质相同:请求把你的分支合并到目标分支。

流程

graph TB
    A[从main创建feature分支] --> B[开发并提交]
    B --> C[推送到远程]
    C --> D[在GitHub创建PR]
    D --> E[代码审查]
    E --> F{通过?}
    F -->|是| G[合并PR]
    F -->|否| H[修改代码]
    H --> B
    G --> I[删除feature分支]

实战示例

# 1. 确保main是最新的
git checkout main
git pull origin main

# 2. 创建功能分支
git checkout -b feature/add-dark-mode

# 3. 开发...
git add .
git commit -m "feat: 添加暗黑模式支持"

# 4. 推送到远程
git push -u origin feature/add-dark-mode

# 5. 去GitHub/GitLab页面创建PR

创建PR时,填写:

  • 标题:简洁描述改动(如"feat: 添加暗黑模式支持")
  • 描述:详细说明改了什么、为什么改、怎么测试
  • 审查者:指定审查代码的人
  • 标签:如enhancement、bug、documentation

好的PR长什么样?

标题格式(约定式提交):

  • feat::新功能
  • fix::bug修复
  • docs::文档更新
  • refactor::重构
  • test::测试
  • chore::杂务(依赖更新、配置等)

描述模板

## 改动描述
添加了暗黑模式支持,用户可以在设置中切换主题。

## 改动原因
用户反馈夜间使用时太刺眼,需要暗黑模式。

## 如何测试
1. 登录系统
2. 进入设置页面
3. 点击"切换主题"
4. 验证页面颜色变化

## 截图
![暗黑模式效果](screenshot.png)

## 相关Issue
Closes #123

一个PR只做一件事

  • 不要把多个不相关的改动塞进一个PR
  • 小PR更容易审查,更快合并
  • 理想大小:200-400行代码

代码审查

代码审查(Code Review)是团队协作的核心。它不仅能发现bug,还能传播知识、统一风格。

审查者看什么?

  1. 正确性:代码是否实现了需求?
  2. 可读性:变量名、函数名是否清晰?逻辑是否易懂?
  3. 性能:有没有明显的性能问题?
  4. 安全:有没有SQL注入、XSS等安全隐患?
  5. 测试:有没有足够的测试覆盖?
  6. 风格:是否符合团队的编码规范?

审查评论类型

必须修改(Blocking)

🛑 这里有个bug,变量未定义就会使用

建议修改(Non-blocking)

💡 建议:这里用Array.filter会更简洁

提问

❓ 为什么要用递归?迭代是不是更合适?

称赞

👍 这个抽象做得很好!

作为被审查者

  1. 不要抵触批评:审查的是代码,不是你这个人
  2. 解释而非辩解:解释为什么这样写,而不是为错误找借口
  3. 及时响应:不要让PR挂着一周不动
  4. 自己先审查一遍:push前自己diff一下,避免低级错误
# 提交前自查
git diff main...HEAD  # 查看当前分支的所有改动

解决PR冲突

PR期间main可能有了新提交,导致你的PR冲突:

# 方法1:merge
git checkout feature/add-dark-mode
git fetch origin
git merge origin/main
# 解决冲突...
git push

# 方法2:rebase(推荐,保持线性历史)
git checkout feature/add-dark-mode
git fetch origin
git rebase origin/main
# 解决冲突...
git push --force-with-lease  # 注意:需要force push

注意--force-with-lease--force更安全,它会在远程有新提交时拒绝push。

Code Owner

大项目可以配置CODEOWNERS文件,自动指定审查者:

# .github/CODEOWNERS

# 前端代码由前端组审查
/frontend/ @myteam/frontend

# API代码由后端组审查
/api/ @myteam/backend

# 安全相关由安全组审查
**/auth* @myteam/security

保护分支

防止直接push到main分支,强制走PR流程:

GitHub设置:

  1. Settings → Branches → Add rule
  2. Branch name pattern: main
  3. 勾选:
    • Require a pull request before merging
    • Require approvals(需要几个人审批)
    • Require status checks to pass before merging(CI必须通过)

这样,任何人(包括管理员)都不能直接push到main,必须通过PR。

CI/CD集成

PR可以触发自动测试,只有测试通过才能合并:

# .github/workflows/test.yml
name: Test

on:
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test
      - run: npm run lint

这样每次PR都会自动跑测试,测试失败就无法合并。

多人协作常见问题

问题1:Push被拒绝

! [rejected] main -> main (non-fast-forward)

原因:远程有新提交,你本地没有。

解决

git pull --rebase origin main
git push origin main

问题2:别人的分支怎么更新?

# 获取所有远程分支
git fetch --all

# 查看同事的分支
git branch -r

# 基于同事的分支创建本地分支
git checkout -b feature-xxx origin/feature-xxx

问题3:如何同步Fork?

# 1. 添加上游仓库
git remote add upstream git@github.com:original-owner/project.git

# 2. 获取上游更新
git fetch upstream

# 3. 合并到本地main
git checkout main
git merge upstream/main

# 4. 推送到你的fork
git push origin main

问题4:不小心push了敏感信息!

# 立即删除敏感文件
git rm --cached config/secrets.yml
git commit -m "chore: 移除敏感文件"
git push

# 历史中还有!需要彻底清除
# 使用BFG Repo-Cleaner(推荐)
bfg --delete-files secrets.yml
git push --force

# 或用git filter-branch(慢)
git filter-branch --force --index-filter \
  'git rm --cached --ignore-unmatch config/secrets.yml' \
  --prune-empty --tag-name-filter cat -- --all
git push --force

重要:改写历史后,所有协作者需要重新clone仓库!

协作规范

Git提交规范

使用约定式提交(Conventional Commits):

(): 

<footer>

示例:

feat(auth): 添加OAuth2.0登录支持

- 支持Google登录
- 支持GitHub登录
- 添加登录状态持久化

Closes #456

好处:

  • 自动生成changelog
  • 自动决定版本号(feat是minor,fix是patch)
  • 清晰的历史记录

提交信息模板

配置提交模板:

git config commit.template ~/.gitmessage

~/.gitmessage内容:

# :  (50 chars)
# |- - - - - - - - - - - - - - - - - - - - - ->|

#  (72 chars)
# |- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ->|

# Type:
#   feat     新功能
#   fix      Bug修复
#   docs     文档
#   style    格式(不影响代码运行)
#   refactor 重构
#   test     测试
#   chore    构建/工具

分支保护策略

graph LR
    A[feature分支] -->|PR| B[develop分支]
    C[bugfix分支] -->|PR| B
    B -->|PR| D[release分支]
    D -->|测试通过| E[main分支]
    F[hotfix分支] -->|PR| E
    E -->|backport| B

小结

你现在掌握了团队协作的核心技能:

  • Fork vs Clone的使用场景
  • Pull Request完整流程
  • 代码审查的最佳实践
  • 解决PR冲突
  • 配置分支保护和CI/CD
  • 多人协作常见问题解决

下一期,我们将进入高级主题——Git钩子和自动化。你会学到如何在commit/push时自动检查代码、运行测试、部署应用。


练习任务

  1. 在GitHub创建一个测试仓库,尝试完整的PR流程
  2. 邀请朋友审查你的PR,练习代码审查对话
  3. 配置一个简单的GitHub Actions,自动运行测试
  4. 尝试在PR中制造冲突并解决

下期预告:《Git高级:钩子与自动化》—— pre-commit怎么配置?如何自动部署?Husky和lint-staged怎么用?

Views: 29

Git分支管理:在平行宇宙中优雅开发

Git分支管理:在平行宇宙中优雅开发

在上一期,我们学会了Git的基本操作。你可能会想:不就是存代码历史嘛,为什么要搞得这么复杂?

答案就在于分支。分支是Git最强大的特性,它允许你在不影响主线的情况下,创建一个平行的开发线,自由实验、开发新功能、修复bug。当你完成工作后,再把分支合并回去。

这就像在写小说时,你想尝试一个大胆的剧情转折。你不需要直接改原文,而是复制一份,在新文件里尽情发挥。如果写得好,就把新版本作为正式版;如果写得烂,直接删掉,原文丝毫不受影响。

分支的本质

在深入之前,先理解分支的本质。

Git的提交不是孤立的,每个提交都包含一个指针,指向上一个提交(父提交)。这样一串提交就形成了一条链。

graph LR
    A[提交1] --> B[提交2] --> C[提交3] --> D[提交4]

分支本质上只是一个指向某个提交的可移动指针。默认分支叫main(以前叫master)。

HEAD是一个特殊指针,指向当前所在的分支。

graph TB
    HEAD --> main
    main --> D[提交4]
    D --> C[提交3] --> B[提交2] --> A[提交1]

当你创建新分支时,Git只是创建了一个新指针,指向当前提交。仓库本身没有变化,快到飞起。

graph TB
    HEAD --> main
    main --> D[提交4]
    feature --> D
    D --> C[提交3] --> B[提交2] --> A[提交1]

分支基本操作

创建分支

# 创建分支(停留在当前分支)
git branch feature-login

# 创建并切换
git checkout -b feature-login

# 新语法(推荐)
git switch -c feature-login

切换分支

# 老语法
git checkout feature-login

# 新语法(推荐)
git switch feature-login

查看分支

# 查看本地分支
git branch

# 查看所有分支(包括远程)
git branch -a

# 查看分支及其最后一次提交
git branch -v

删除分支

# 删除已合并的分支
git branch -d feature-login

# 强制删除(未合并也删)
git branch -D feature-login

重命名分支

# 重命名当前分支
git branch -m new-name

# 重命名指定分支
git branch -m old-name new-name

分支工作流

Feature Branch工作流

这是最常用的分支策略。每开发一个新功能,就创建一个分支,开发完成后合并回主线。

# 1. 从main创建功能分支
git checkout main
git pull
git checkout -b feature-user-profile

# 2. 开发中...频繁提交
git add .
git commit -m "feat: 添加用户头像上传"

git add .
git commit -m "feat: 添加用户简介编辑"

# 3. 开发完成,合并回main
git checkout main
git pull  # 先更新main
git merge feature-user-profile

# 4. 删除功能分支
git branch -d feature-user-profile

Git Flow工作流

更复杂的团队协作模型,定义了几种分支类型:

  • main:生产环境代码,永远是稳定的
  • develop:开发分支,集成各个功能
  • **feature/***:功能分支,从develop分出,合并回develop
  • **release/***:发布分支,从develop分出,准备发布
  • **hotfix/***:紧急修复分支,从main分出,合并回main和develop
gitGraph
    commit id: "init"
    branch develop
    checkout develop
    commit id: "dev1"
    branch feature-A
    checkout feature-A
    commit id: "feat1"
    commit id: "feat2"
    checkout develop
    merge feature-A id: "merge-A"
    checkout main
    branch hotfix
    checkout hotfix
    commit id: "fix"
    checkout main
    merge hotfix id: "hotfix-merge"
    checkout develop
    merge hotfix

小团队不需要这么复杂,Feature Branch足够用了。

合并分支

快进合并(Fast-forward)

如果main分支在你分出feature后没有任何新提交,Git会直接把main指针移到feature的最新提交。

git checkout main
git merge feature-login
# 输出:Fast-forward

这种合并不产生新的提交节点,历史是线性的。

三方合并(Three-way merge)

如果main分支有了新提交,Git会找到两个分支的共同祖先,做一个三方合并,产生一个新的合并提交。

git checkout main
git merge feature-login
# 输出:Merge made by the 'recursive' strategy.
graph TB
    subgraph 合并前
    A[共同祖先] --> B[main新提交]
    A --> C[feature提交]
    end
graph TB
    subgraph 合并后
    A[共同祖先] --> B[main新提交]
    A --> C[feature提交]
    B --> D[合并提交]
    C --> D
    end

禁用快进合并

有时候你想保留分支历史,即使是快进合并也产生一个合并节点:

git merge --no-ff feature-login

这样历史会更清晰地显示"这里曾经有个分支"。

冲突解决

这是新手最害怕的部分。当两个分支修改了同一文件的同一行,Git无法自动合并,就会产生冲突。

模拟冲突

# 分支1修改readme.md第一行
echo "Version A" > readme.md
git add readme.md
git commit -m "Version A"

# 切回main,也修改第一行
git checkout main
echo "Version B" > readme.md
git add readme.md
git commit -m "Version B"

# 尝试合并
git merge feature-xxx
# 冲突!

Git会告诉你哪些文件冲突了:

CONFLICT (content): Merge conflict in readme.md
Automatic merge failed; fix conflicts and then commit the result.

打开冲突文件,你会看到:

<<<<<<>>>>>> feature-xxx
  • <<<<<<>>>>>> feature-xxx:要合并的分支内容

手动解决冲突

  1. 删除标记符号
  2. 保留正确的内容(或两者都保留)
  3. 保存文件
  4. git add + git commit
# 解决后
echo "Version A and B combined" > readme.md
git add readme.md
git commit -m "merge: 解决readme冲突"

使用合并工具

# 使用配置的合并工具(如VSCode)
git mergetool

放弃合并

git merge --abort

变基(Rebase)

merge会产生分叉的历史,有些人喜欢线性的历史。这时候可以用rebase。

merge vs rebase

gitGraph
    commit id: "A"
    commit id: "B"
    branch feature
    checkout feature
    commit id: "C"
    commit id: "D"
    checkout main
    commit id: "E"

用merge

gitGraph
    commit id: "A"
    commit id: "B"
    branch feature
    checkout feature
    commit id: "C"
    commit id: "D"
    checkout main
    commit id: "E"
    merge feature id: "M"

用rebase

gitGraph
    commit id: "A"
    commit id: "B"
    commit id: "E"
    commit id: "C'"
    commit id: "D'"
# 在feature分支上执行
git checkout feature
git rebase main

rebase会把feature上的提交"移到"main的最新提交之后,历史变成线性的。

黄金法则永远不要rebase已经push到远程的提交。因为这会改写历史,给队友带来灾难。

交互式rebase

# 修改最近3个提交
git rebase -i HEAD~3

这会打开编辑器,你可以:

  • pick:保留提交
  • squash:合并到前一个提交
  • reword:修改提交信息
  • drop:删除提交
  • edit:暂停以便修改这个提交

Stash:临时保存

开发到一半,突然需要切换分支处理紧急事务,但当前工作还没完成,不想commit怎么办?

# 保存当前工作
git stash

# 带描述保存
git stash save "WIP: 用户登录功能"

# 查看stash列表
git stash list

# 恢复最近的stash
git stash pop

# 恢复但不删除
git stash apply

# 恢复指定stash
git stash apply stash@{2}

# 删除stash
git stash drop stash@{0}

# 清空所有stash
git stash clear

Cherry-pick:选择性合并

只想合并某个分支的一个特定提交?用cherry-pick:

# 先在目标分支找到提交hash
git checkout feature-A
git log --oneline
# 假设要合并的提交是 a1b2c3d

# 切回main,cherry-pick
git checkout main
git cherry-pick a1b2c3d

这会把那个提交的改动复制到当前分支,产生一个新的提交。

分支最佳实践

  1. 分支命名规范

    • feature/xxx:新功能
    • bugfix/xxx:bug修复
    • hotfix/xxx:紧急修复
    • release/x.x.x:发布准备
    • experiment/xxx:实验性功能
  2. 及时删除已合并分支

    # 删除本地
    git branch -d feature-xxx
    
    # 删除远程
    git push origin --delete feature-xxx
  3. 保持分支短小

    • 一个分支只做一件事
    • 频繁合并回主线,避免长寿命分支
  4. 提交前先pull

    git checkout main
    git pull --rebase  # 用rebase避免不必要的merge提交
  5. 使用Pull Request / Merge Request
    不要直接在本地合并,通过PR让代码经过review再合并。

小结

你现在掌握了Git分支的核心技能:

  • 理解分支的本质(可移动指针)
  • 创建、切换、删除分支
  • 合并分支(快进和三方合并)
  • 解决合并冲突
  • 使用rebase保持线性历史
  • stash临时保存工作
  • cherry-pick选择性合并

下一期,我们将进入团队协作。你会学到如何用Git在团队中高效工作,包括Pull Request流程、代码审查、多人协作的最佳实践。


练习任务

  1. 创建一个feature分支,提交几次后合并回main
  2. 制造一个冲突并手动解决
  3. 尝试git rebase -i合并最近2个提交
  4. 用stash保存当前工作,切换分支后再恢复

下期预告:《Git协作:团队开发流程》—— Pull Request怎么做?代码审查看什么?多人协作怎么避免灾难?

Views: 14

Git入门指南:从零开始掌握版本控制

Git入门指南:从零开始掌握版本控制

Git Logo

你有没有经历过这样的噩梦?项目文件夹里到处是 最终版.doc最终版2.doc打死不改版.doc真的最后版.doc...每次回滚代码都要手动复制备份,团队协作时互相覆盖文件,谁改了什么完全不知道。

这就是没有版本控制的痛。而Git,就是终结这一切的利器。

什么是版本控制?

想象你在写一本小说,每写完一章就保存一个副本。突然你发现第三章的情节有问题,想回到第二章重新写。如果没有版本控制,你只能手动翻备份文件夹,祈祷自己当时保存了。

版本控制系统就像是给项目装了一个时光机。它记录了每次修改的快照,你可以随时回到任意历史版本,查看谁在什么时候改了什么,甚至可以创建平行世界(分支)来尝试不同的剧情走向。

为什么是Git?

2005年,Linux内核开发社区遭遇了一场危机:他们使用的专有版本控制系统BitKeeper不再免费提供。Linux之父Linus Torvalds在短短两周内开发出了Git的初始版本。

Git的设计哲学很简单:快、简单、支持非线性开发(成千上万个并行分支)、完全分布式。这些特性让它迅速成为全球最流行的版本控制系统。今天,从Google到Microsoft,从Facebook到阿里巴巴,几乎每家科技公司都在用Git。

安装Git

Windows用户
从官网下载安装包(https://git-scm.com/download/win),一路下一步即可。安装完成后,右键菜单会多出"Git Bash Here"选项,这就是你的Git命令行工具。

Mac用户
最简单的方式是安装Xcode Command Line Tools:

xcode-select --install

或者用Homebrew:

brew install git

Linux用户
Debian/Ubuntu:

sudo apt-get install git

CentOS/RHEL:

sudo yum install git

安装完成后,验证一下:

git --version

看到版本号就说明安装成功了。

第一次配置

Git需要知道你是谁,因为每次提交都会记录作者信息。打开终端,运行:

git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

这里的名字和邮箱最好和你的GitHub/GitLab账号一致,这样后续协作会更方便。

查看配置:

git config --list

创建你的第一个仓库

方式一:初始化新仓库

创建一个新项目文件夹,进入后执行:

mkdir my-first-project
cd my-first-project
git init

这时候Git会在当前目录创建一个隐藏的.git文件夹,所有版本信息都存在这里。

方式二:克隆已有仓库

如果项目已经存在于远程(比如GitHub),直接克隆:

git clone https://github.com/username/repo.git

理解Git的三个区域

这是理解Git最关键的概念。Git有三个逻辑区域:

  1. 工作区(Working Directory):你看到的文件,正在编辑的地方
  2. 暂存区(Staging Area/Index):准备提交的修改,像购物车
  3. 版本库(Repository):已提交的历史记录,像仓库
graph LR
    A[工作区] -->|git add| B[暂存区]
    B -->|git commit| C[版本库]
    C -->|git checkout| A

为什么需要暂存区?

假设你修改了三个文件:A、B、C。其中A和B是同一个功能,C是另一个功能。你可以把A和B先add到暂存区,commit成一个提交;然后再add C,commit成另一个提交。这样提交历史就很清晰,而不是把所有修改混在一起。

日常操作流程

1. 查看状态

git status

这是最常用的命令,告诉你哪些文件被修改了,哪些在暂存区,哪些还没被跟踪。

2. 添加到暂存区

# 添加单个文件
git add filename.txt

# 添加所有修改
git add .

# 添加所有修改(包括删除)
git add -A

3. 提交到版本库

git commit -m "简洁的提交信息"

提交信息很重要!好的提交信息应该回答:做了什么修改?为什么这样修改?

4. 查看历史

# 完整历史
git log

# 简洁版(一行一个提交)
git log --oneline

# 图形化显示分支
git log --oneline --graph --all

5. 查看差异

# 工作区 vs 暂存区
git diff

# 暂存区 vs 最新提交
git diff --staged

# 两个提交之间
git diff commit1 commit2

撤销操作(救你于水火)

撤销工作区修改

# 丢弃单个文件的修改(危险操作!)
git checkout -- filename.txt

# 或者用新语法
git restore filename.txt

撤销暂存

# 把文件从暂存区移回工作区
git reset HEAD filename.txt

# 或者用新语法
git restore --staged filename.txt

修改最后一次提交

# 还没push,发现提交信息写错了
git commit --amend -m "正确的提交信息"

# 还没push,漏了一个文件
git add forgotten-file.txt
git commit --amend --no-edit

注意--amend会改写历史,如果已经push了就不要用,否则会给队友带来麻烦。

忽略文件

有些文件不需要纳入版本控制,比如编译产物、日志文件、IDE配置等。在项目根目录创建.gitignore文件:

# 编译产物
*.o
*.exe
build/

# 日志
*.log

# IDE配置
.idea/
.vscode/

# 系统文件
.DS_Store
Thumbs.db

# 依赖目录
node_modules/
.venv/

GitHub有个awesome-gitignore仓库,收集了各种项目的.gitignore模板,值得收藏。

远程仓库

关联远程仓库

# 添加远程仓库
git remote add origin https://github.com/username/repo.git

# 查看远程仓库
git remote -v

推送代码

# 第一次推送(设置上游分支)
git push -u origin main

# 之后推送
git push

拉取代码

# 拉取并合并
git pull

# 只拉取不合并
git fetch

git pull = git fetch + git merge。建议先fetch看看有什么变化,再决定要不要merge。

SSH配置(告别密码)

每次push都要输入密码很烦?配置SSH密钥:

# 生成密钥对
ssh-keygen -t ed25519 -C "你的邮箱"

# 查看公钥
cat ~/.ssh/id_ed25519.pub

把公钥复制到GitHub的Settings → SSH Keys。然后把远程地址改成SSH格式:

git remote set-url origin git@github.com:username/repo.git

现在push再也不用输密码了。

小结

恭喜你,掌握了Git的基础用法。你现在可以:

  • 创建和管理仓库
  • 理解工作区、暂存区、版本库
  • 进行日常的add、commit、push、pull操作
  • 撤销误操作
  • 配置.gitignore和SSH

但这只是Git冰山一角。下一期,我们将深入分支管理——Git最强大的功能之一。你会学会如何创建平行宇宙,在不同的开发线之间自由穿梭,最后把它们完美合并。


练习任务

  1. 创建一个新仓库,提交至少3次
  2. 尝试修改文件后用git checkout撤销
  3. 故意add一个文件,然后用git reset HEAD撤销暂存
  4. 在GitHub创建仓库,把本地代码push上去

做完这些,你就真正入门Git了。


下期预告:《Git进阶:分支管理艺术》—— 什么时候该开分支?如何优雅地合并?冲突了怎么办?

Views: 26