git命令详细教程(除此之外内含企业级开源项目应该养成的git规范，旨在帮助更多新人养成良好的习惯)

原创 已于 2025-08-11 19:10:31 修改 · 921 阅读 · 28 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#git #分布式 #github

于 2025-08-11 19:04:26 首次发布

Git 使用说明

目录

1. 什么是Git？

1.1 使用场景

版本控制的需求其实在我们生活中随处可见，让我们从几个熟悉的场景开始理解：

场景一：写论文

想象一下你今年大四或者是在读研读博，正在写毕业论文：

没有版本控制的痛苦：

  • 你花了两周写了第一稿，导师说结构需要大改，但你已经记不清最初的想法了
  • 你创建了论文_初稿.docx、论文_修改版.docx、论文_最终版.docx、论文_真的最终版.docx、论文_导师修改后.docx等无数个文件
  • 当你最后一次通宵贯通好修改了无数个版本的文件后，发给了导师，导师却说还是选择第一版吧
  • 你想知道昨天删掉的那段话是什么，但只能靠记忆
场景二：程序员开发项目

你是一名程序员，正在开发一个网站：

没有版本控制的痛苦经历：

  • 你写了一周的代码，突然发现新功能有问题，想回到之前的版本，但是只能用Ctrl+Z撤销，而且只能撤销有限的步骤
  • 你想保存不同的版本，于是创建了项目_v1.0、项目_v1.1、项目_v1.2_修复bug、项目_v1.3_最终版、项目_v1.4_真正最终版等文件夹
  • 你和同事一起开发，你们通过邮件或微信传文件，经常出现版本冲突，不知道谁的代码是最新的
  • 某天电脑坏了，所有代码都丢失了，几个月的心血付之东流
场景四：设计师制作作品集

一名平面设计师在制作客户的品牌设计：

版本管理的噩梦：

  • 客户看了设计稿后要求修改，但两天后又说还是喜欢第一版
  • 你需要向客户展示设计的演进过程，但文件名混乱，找不到对应版本
  • 多个设计师协作时，不知道谁改了什么，为什么要这样改

有了Git这样的版本控制系统之后：

✅ 完整的历史记录：每次修改都有完整的记录，可以随时回到任何一个历史版本
✅ 清晰的版本管理：不再需要创建无数个文件副本，一个文件夹就能管理所有版本
✅ 协作变简单：多人协作变得简单，系统会自动处理内容合并和冲突
✅ 永不丢失：内容保存在多个地方（本地、远程服务器），不用担心丢失
✅ 变更追踪：清楚地知道什么时候、谁、为什么做了什么修改
✅ 并行开发：可以同时尝试不同的想法和方案，互不干扰

Git就是为了解决这些普遍存在的版本管理问题而诞生的分布式版本控制系统。虽然它最初是为软件开发而设计的，但其核心思想适用于任何需要版本管理的场景。

1.2 Git的核心概念

Git可以理解为一个"时光机"：

  • 记录变化：它不是简单地保存文件，而是记录文件的每一次变化
  • 时间轴：每次提交(commit)就像在时间轴上打下一个标记
  • 并行宇宙：不同的分支就像不同的平行宇宙，可以独立发展，也可以合并

2. Git与其他工具的对比

2.1 与传统版本控制系统的区别

特性传统版本控制(如SVN)Git
架构集中式分布式
网络依赖需要连接服务器大部分操作可离线
性能相对较慢非常快
分支分支操作较重分支操作轻量级
数据完整性依赖服务器每个副本都是完整的

集中式 vs 分布式的形象比喻：

  • 集中式：就像一个图书馆，所有书都在图书馆里，你要借书必须去图书馆，还书也要去图书馆
  • 分布式：就像每个人都有一个完整的图书馆副本，可以在家里随意阅读，偶尔大家聚在一起同步一下新书

2.2 Git的优缺点

优点：

  • ⭐ 速度快：大部分操作都在本地进行，不需要网络
  • ⭐ 完全分布式：每个开发者都有完整的代码历史
  • ⭐ 强大的分支功能：创建、切换、合并分支都非常快
  • ⭐ 数据完整性：使用SHA-1哈希确保数据不被篡改
  • ⭐ 灵活的工作流：支持各种开发模式

缺点：

  • ❌ 学习曲线陡峭：概念较多，初学者容易困惑
  • ❌ 不适合二进制文件：对于大型二进制文件支持不够好
  • ❌ 权限控制相对简单：不如某些企业级工具精细

2.3 为什么选择Git

  1. 行业标准：几乎所有的开源项目都使用Git
  2. 就业必备：现在的程序员岗位基本都要求会Git
  3. 生态完善：GitHub、GitLab等平台提供了完整的开发生态
  4. 免费开源：Git本身完全免费，社区活跃
  5. 工具丰富：有大量的图形化工具和IDE集成

3. Git基础概念

3.1 仓库(Repository)

仓库就是一个项目的完整历史记录存储位置。

项目文件夹/
├── .git/           # Git仓库数据（隐藏文件夹）
├── src/            # 你的源代码
├── README.md       # 项目说明
└── package.json    # 项目配置
  • .git文件夹：这是Git的"大脑"，存储所有的版本信息
  • 工作目录：你平时编辑的文件所在的地方

3.2 工作区、暂存区和版本库

这是Git最重要的概念，可以用一个餐厅的比喻来理解：

工作区 (Working Directory)     暂存区 (Staging Area)      版本库 (Repository)
    厨房                          传菜窗口                    	餐桌
    👨‍🍳                           	📋                        	 📚
  正在做菜                       准备上菜的菜                已上菜的历史记录
  • 工作区：你正在编辑的文件，就像厨师在厨房做菜
  • 暂存区：准备提交的文件，就像做好的菜放在传菜窗口
  • 版本库：已经提交的版本，就像顾客已经吃到的菜

操作流程：

# 1. 在工作区修改文件
# 2. 添加到暂存区
git add filename
# 3. 提交到版本库
git commit -m "提交说明"

3.3 分支(Branch)

分支就像平行宇宙，让你可以同时进行不同的开发工作。

主分支 master:  A --- B --- C --- D
                    \
功能分支 feature:     E --- F

实际应用场景：

  • master分支：稳定的主要代码
  • feature分支：开发新功能
  • bugfix分支：修复bug
  • test分支：测试新想法

3.4 提交(Commit)

每次提交就像拍了一张代码的"快照"，记录了：

  • 谁在什么时间
  • 修改了什么
  • 为什么修改

4. Git基础操作

4.1 初始化和配置

首次使用Git需要配置身份：

# 设置用户名
git config --global user.name "你的姓名"

# 设置邮箱
git config --global user.email "your.email@example.com"

# 查看配置
git config --list

初始化仓库：

# 在现有项目中初始化Git仓库
git init

# 克隆远程仓库
git clone https://github.com/用户名/项目名.git

4.2 基本工作流程

日常开发的标准流程：

# 1. 查看当前状态
git status

# 2. 添加文件到暂存区
git add 文件名              # 添加单个文件
git add .                  # 添加所有文件
git add *.js              # 添加所有js文件

# 3. 提交到版本库
git commit -m "添加用户登录功能"

# 4. 推送到远程仓库
git push origin main

实际操作示例：

# 你修改了一个文件 app.js
echo "console.log('Hello Git');" > app.js

# 查看状态
git status
# 输出：modified: app.js

# 添加到暂存区
git add app.js

# 再次查看状态
git status
# 输出：Changes to be committed: modified: app.js

# 提交
git commit -m "添加Hello Git输出"

# 查看提交历史
git log --oneline

4.3 查看状态和历史

# 查看当前状态
git status

# 查看提交历史
git log                    # 详细历史
git log --oneline         # 简化历史
git log --graph           # 图形化显示分支

# 查看文件差异
git diff                  # 工作区与暂存区的差异
git diff --cached         # 暂存区与版本库的差异
git diff HEAD             # 工作区与版本库的差异

# 查看具体文件的修改
git show commit-id        # 查看某次提交的详细内容

5. 分支管理

5.1 分支基础操作

# 查看分支
git branch                # 查看本地分支
git branch -r             # 查看远程分支
git branch -a             # 查看所有分支

# 创建分支
git branch 分支名         # 创建但不切换
git checkout -b 分支名    # 创建并切换

# 切换分支
git checkout 分支名
git switch 分支名         # Git 2.23+的新命令

# 删除分支
git branch -d 分支名      # 删除已合并的分支
git branch -D 分支名      # 强制删除分支

分支开发实例：

# 从master创建并切换到功能分支
git checkout -b feature-login

# 开发登录功能，修改文件后提交
git add login.js
git commit -m "实现用户登录功能"

# 切换回主分支
git checkout master

# 合并功能分支
git merge feature-login

# 删除功能分支
git branch -d feature-login

5.2 分支合并

合并方式：

  1. 快速合并 (Fast-forward)
git merge feature-branch
  1. 三方合并 (Three-way merge)
git merge --no-ff feature-branch
  1. 变基合并 (Rebase)
git rebase master

合并冲突解决：

# 当合并出现冲突时
git merge feature-branch
# 输出：CONFLICT (content): Merge conflict in file.js

# 1. 打开冲突文件，会看到：
<<<<<<< HEAD
当前分支的代码
=======
要合并分支的代码
>>>>>>> feature-branch

# 2. 手动编辑解决冲突

# 3. 添加解决后的文件
git add file.js

# 4. 完成合并
git commit

5.3 分支策略

常见的分支模型：

  1. Git Flow

    • master：生产环境
    • develop：开发环境
    • feature：功能开发
    • release：发布准备
    • hotfix：紧急修复

  2. GitHub Flow

    • master：主分支
    • feature：功能分支
    • 通过Pull Request合并

6. 远程仓库

6.1 什么是远程仓库

远程仓库是存储在网络上或其他位置的Git仓库，它是你本地仓库的"镜像"或"备份"。

为什么需要远程仓库？
  1. 备份安全：你的代码不仅存在本地，还有远程备份
  2. 团队协作：多个开发者可以通过远程仓库共享代码
  3. 版本同步：确保团队成员都在使用最新的代码
  4. 持续集成：自动化构建和部署可以从远程仓库获取代码
  5. 开源分享：可以将代码分享给全世界的开发者
远程仓库的形象比喻

可以把远程仓库理解为"云端图书馆"：

  • 本地仓库：你家里的私人书房，可以随时阅读和修改
  • 远程仓库：图书馆总馆，大家都可以访问，是权威版本
  • 推送(push)：把你的新书（代码修改）捐赠给图书馆
  • 拉取(pull)：从图书馆借阅最新的书籍回家
  • 克隆(clone)：把整个图书馆复制一份到你家
常见的远程仓库托管服务
服务商特点适用场景
GitHub全球最大的代码托管平台开源项目、个人项目
GitLab提供完整的DevOps解决方案企业项目、私有部署
Gitee国内的代码托管平台国内团队、中文界面
BitbucketAtlassian旗下，与Jira集成好企业项目管理

6.2 添加和管理远程仓库

查看现有的远程仓库：

# 查看远程仓库列表
git remote
# 输出：origin

# 查看远程仓库详细信息（包含URL）
git remote -v
# 输出：
# origin  https://github.com/username/repo.git (fetch)
# origin  https://github.com/username/repo.git (push)

添加远程仓库：

# 添加远程仓库（origin是默认的远程仓库名称）
git remote add origin https://github.com/用户名/仓库名.git
  • 作用：将远程仓库与本地仓库关联起来
  • origin：这是远程仓库的默认名称，你也可以使用其他名称
  • 为什么要添加：只有添加了远程仓库，才能进行推送、拉取等操作

管理多个远程仓库：

# 添加多个远程仓库（比如你fork了一个项目）
git remote add origin https://github.com/你的用户名/项目名.git     # 你的仓库
git remote add upstream https://github.com/原作者/项目名.git       # 原始仓库

# 查看所有远程仓库
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)

修改和删除远程仓库：

# 修改远程仓库地址（比如从HTTPS改为SSH）
git remote set-url origin git@github.com:用户名/仓库名.git

# 重命名远程仓库
git remote rename origin new-origin

# 删除远程仓库关联
git remote remove origin

6.3 推送和拉取

推送(Push)操作

推送就是将本地的提交上传到远程仓库。

# 推送当前分支到远程仓库
git push origin 分支名

# 推送master分支
git push origin master
  • 作用：将本地的新提交发送到远程仓库
  • 为什么要推送：让其他人能看到你的代码修改，同时备份代码
# 首次推送（设置上游分支）
git push -u origin master
  • -u参数：设置上游分支，以后只需要git push就能推送到origin master
  • 上游分支：告诉Git你的本地分支对应哪个远程分支
# 推送所有分支
git push origin --all

# 推送标签
git push origin --tags

# 强制推送（危险操作，会覆盖远程分支）
git push -f origin master
拉取(Pull/Fetch)操作

拉取就是从远程仓库下载最新的代码到本地。

fetch vs pull的区别：

  • fetch：只下载，不合并（安全）
  • pull：下载并自动合并（等于fetch + merge）
# 获取远程仓库的更新（不合并）
git fetch origin
  • 作用：下载远程仓库的最新提交到本地，但不影响你的工作区
  • 安全性：不会修改你的代码，可以先查看远程更新内容
# 查看远程分支情况
git branch -r

# 查看远程和本地的差异
git log HEAD..origin/master

# 手动合并远程分支
git merge origin/master

# 拉取并自动合并（常用）
git pull origin master
  • 作用：相当于先fetch再merge，直接更新你的工作分支
  • 注意：如果有冲突需要手动解决
# 拉取当前分支（已设置上游分支的情况下）
git pull
推送拉取的完整工作流程
# 1. 开始工作前，先拉取最新代码
git pull origin master

# 2. 进行开发工作
# 编辑文件...

# 3. 提交代码
git add .
git commit -m "完成新功能"

# 4. 推送前再次拉取（防止其他人提交了新代码）
git pull origin master

# 5. 推送到远程仓库
git push origin master

6.4 多人协作

协作流程：

# 1. 克隆项目
git clone https://github.com/team/project.git

# 2. 创建功能分支
git checkout -b feature-payment

# 3. 开发功能并提交
git add .
git commit -m "添加支付功能"

# 4. 推送分支
git push origin feature-payment

# 5. 在GitHub创建Pull Request

# 6. 代码审查后合并

# 7. 删除本地功能分支
git branch -d feature-payment

保持同步：

# 切换到主分支
git checkout master

# 拉取最新代码
git pull origin master

# 基于最新代码创建新分支
git checkout -b new-feature

7. 进阶操作

7.1 版本回退和撤销

# 查看提交历史
git log --oneline

# 回退到上一个版本
git reset --hard HEAD^
git reset --hard HEAD~1

# 回退到指定版本
git reset --hard commit-id

# 撤销工作区的修改
git checkout -- 文件名

# 撤销暂存区的修改
git reset HEAD 文件名

# 撤销最后一次提交（保留修改）
git reset --soft HEAD^

# 修改最后一次提交信息
git commit --amend

reset三种模式：

  • --soft：只移动HEAD指针
  • --mixed：移动HEAD并重置暂存区（默认）
  • --hard：移动HEAD、重置暂存区和工作区

7.2 储藏和清理

储藏(Stash)操作

储藏用于临时保存工作进度，当你需要快速切换分支但又不想提交当前的修改时。

# 储藏当前工作区的修改
git stash
# 等同于：git stash push -m "WIP on branch_name"
  • 作用：临时保存未提交的修改，让工作区变得干净
  • 场景：正在开发功能A，突然需要紧急修复bug，可以先stash再切换分支
# 储藏时添加描述信息
git stash save "正在开发用户登录功能"

# 查看储藏列表
git stash list
# 输出：
# stash@{0}: WIP on feature-login: 1234567 添加登录按钮
# stash@{1}: On master: abcdefg 正在开发用户登录功能

# 查看储藏的具体内容
git stash show stash@{0}
git stash show -p stash@{0}  # 查看详细差异

# 恢复储藏的内容
git stash pop              # 恢复最新的储藏并删除储藏记录
git stash apply            # 恢复最新的储藏但保留储藏记录
git stash apply stash@{1}  # 恢复指定的储藏

# 删除储藏
git stash drop stash@{0}   # 删除指定储藏
git stash clear           # 删除所有储藏
清理操作
# 查看将要删除的文件（干运行）
git clean -n

# 删除未跟踪的文件
git clean -f

# 删除未跟踪的文件和目录
git clean -fd

# 删除被忽略的文件
git clean -fX

# 删除所有未跟踪的文件（包括被忽略的）
git clean -fx

7.3 变基操作

什么是变基(Rebase)？

变基是将一系列提交重新应用到另一个基点上，可以让提交历史更加线性和清晰。

# 基本变基操作
git rebase master
  • 作用：将当前分支的提交"移动"到master分支的最新提交之后
  • 效果：让提交历史看起来像是在最新的master基础上开发的
变基 vs 合并
操作结果历史记录使用场景
merge三方合并保留分支历史功能完成后的合并
rebase线性历史重写提交历史保持历史整洁

图解对比：

# 合并前
A---B---C (master)
     \
      D---E (feature)

# merge后
A---B---C---F (master)
     \     /
      D---E

# rebase后
A---B---C---D'---E' (feature)
交互式变基
# 交互式变基最近3个提交
git rebase -i HEAD~3

交互式变基可以：

  • pick：保留提交
  • reword：修改提交信息
  • edit：修改提交内容
  • squash：将提交合并到前一个提交
  • drop：删除提交

7.4 标签管理

# 创建标签
git tag v1.0              # 轻量标签
git tag -a v1.0 -m "版本1.0发布"  # 附注标签

# 在指定提交上创建标签
git tag v0.9 commit-hash

# 查看标签
git tag                   # 列出所有标签
git tag -l "v1.*"        # 列出匹配的标签
git show v1.0             # 查看标签详细信息

# 推送标签
git push origin v1.0      # 推送单个标签
git push origin --tags    # 推送所有标签

# 删除标签
git tag -d v1.0           # 删除本地标签
git push origin :refs/tags/v1.0  # 删除远程标签
git push origin --delete v1.0    # 删除远程标签（新语法）

7.5 子模块

子模块允许你将一个Git仓库作为另一个Git仓库的子目录。

# 添加子模块
git submodule add https://github.com/user/repo.git path/to/submodule

# 初始化子模块
git submodule init

# 更新子模块
git submodule update

# 一次性初始化并更新所有子模块
git submodule update --init --recursive

# 更新子模块到最新版本
git submodule update --remote

# 查看子模块状态
git submodule status

7.6 配置文件

Git配置级别：

  1. --system：系统级别（所有用户）
  2. --global：用户级别（当前用户）
  3. --local：仓库级别（当前仓库）
# 常用配置
git config --global user.name "姓名"
git config --global user.email "邮箱"
git config --global core.editor "code"  # 设置默认编辑器
git config --global init.defaultBranch main  # 设置默认分支名

# 别名配置
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 --list
git config user.name

8. Git钩子和自动化

8.1 什么是Git钩子

Git钩子是在Git操作的特定时间点自动执行的脚本，可以用来自动化工作流程。

常用钩子类型
钩子名称触发时机常用场景
pre-commit提交前代码格式检查、测试运行
commit-msg提交信息输入后验证提交信息格式
pre-push推送前运行测试、构建检查
post-receive接收推送后自动部署

8.2 钩子示例

pre-commit钩子示例（代码格式检查）：

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

# 运行代码格式检查
npm run lint
if [ $? -ne 0 ]; then
    echo "代码格式检查失败，请修复后重新提交"
    exit 1
fi

# 运行测试
npm test
if [ $? -ne 0 ]; then
    echo "测试失败，请修复后重新提交"
    exit 1
fi

commit-msg钩子示例（提交信息格式验证）：

#!/bin/sh
# .git/hooks/commit-msg

commit_regex='^(feat|fix|docs|style|refactor|test|chore)(\(.+\))?: .{1,50}'

if ! grep -qE "$commit_regex" "$1"; then
    echo "无效的提交信息格式！"
    echo "格式应该为: type(scope): description"
    echo "例如: feat(auth): 添加用户登录功能"
    exit 1
fi

8.3 使用Husky管理钩子

Husky是一个流行的Git钩子管理工具：

# 安装husky
npm install --save-dev husky

# 启用husky
npx husky install

# 添加pre-commit钩子
npx husky add .husky/pre-commit "npm test"

# 添加commit-msg钩子
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

9. 常见问题和解决方案

问题1：提交了错误的文件

# 如果还没推送，可以修改最后一次提交
git reset --soft HEAD^
# 重新添加正确的文件
git add 正确的文件
git commit -m "正确的提交信息"

问题2：忘记切换分支就开始开发

# 如果修改还没提交，可以暂存修改
git stash
git checkout 正确的分支
git stash pop

问题3：合并时出现冲突

# 1. 查看冲突文件
git status

# 2. 编辑冲突文件，解决冲突

# 3. 标记为已解决
git add 冲突文件

# 4. 完成合并
git commit

问题4：误删了文件

# 恢复删除的文件
git checkout HEAD -- 文件名

# 或者从指定版本恢复
git checkout commit-id -- 文件名

问题5：提交信息写错了

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

问题6：想临时保存工作进度

# 暂存当前工作
git stash

# 查看暂存列表
git stash list

# 恢复暂存的工作
git stash pop

# 删除暂存
git stash drop

问题7：推送被拒绝

# 原因：远程仓库有新的提交
# 解决：先拉取再推送
git pull origin master
git push origin master

问题8：想要撤销已推送的提交

# 方法1：使用revert（推荐，安全）
git revert commit-id

# 方法2：强制推送（危险，会影响其他人）
git reset --hard HEAD^
git push -f origin master

问题9：合并时出现"non-fast-forward"错误

# 错误信息：Updates were rejected because the remote contains work that you do not have locally
# 原因：远程分支有新的提交
# 解决方法：
git pull origin master
git push origin master

# 或者使用rebase保持线性历史
git pull --rebase origin master
git push origin master

问题10：想要修改历史提交的信息

# 修改最近一次提交
git commit --amend -m "新的提交信息"

# 修改历史提交（交互式rebase）
git rebase -i HEAD~3  # 修改最近3个提交
# 在编辑器中将要修改的提交前的"pick"改为"reword"

问题11：不小心提交了敏感信息（密码、密钥等）

# 如果还没推送
git reset --soft HEAD^
git reset HEAD 敏感文件
# 编辑文件删除敏感信息
git add .
git commit -m "移除敏感信息"

# 如果已经推送，需要从历史中完全移除
git filter-branch --force --index-filter \
'git rm --cached --ignore-unmatch 敏感文件' \
--prune-empty --tag-name-filter cat -- --all

# 强制推送（警告：这会改写历史）
git push origin --force --all

问题12：想要找到引入bug的提交

# 使用git bisect进行二分查找
git bisect start
git bisect bad HEAD          # 当前版本有bug
git bisect good v1.0        # v1.0版本没有bug

# Git会自动切换到中间的提交，测试后标记：
git bisect good    # 如果这个版本没有bug
git bisect bad     # 如果这个版本有bug

# 重复直到找到引入bug的提交
git bisect reset   # 结束bisect回到原来的分支

问题13：分支名字写错了，想要重命名

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

# 重命名其他分支
git branch -m 旧分支名 新分支名

# 如果已经推送到远程
git push origin :旧分支名        # 删除远程旧分支
git push origin 新分支名         # 推送新分支
git push origin -u 新分支名      # 设置上游分支

问题14：文件太大，推送失败

# 错误：file size exceeds GitHub's file size limit of 100 MB

# 方法1：使用Git LFS（大文件存储）
git lfs install
git lfs track "*.zip"      # 跟踪大文件类型
git add .gitattributes
git add 大文件.zip
git commit -m "添加大文件支持"

# 方法2：从历史中移除大文件
git filter-branch --tree-filter 'rm -f 大文件.zip' HEAD

问题15：想要查看某个文件的修改历史

# 查看文件的提交历史
git log --follow -p 文件名

# 查看文件在某个时间点的内容
git show commit-id:文件名

# 查看文件每行的最后修改者
git blame 文件名

# 查看文件在不同版本间的差异
git diff HEAD~2 HEAD 文件名

问题16：克隆很慢或失败

# 浅克隆（只下载最近的提交）
git clone --depth 1 https://github.com/user/repo.git

# 只克隆单个分支
git clone -b master --single-branch https://github.com/user/repo.git

# 使用SSH代替HTTPS
git clone git@github.com:user/repo.git

# 如果需要后续获取完整历史
git fetch --unshallow

问题17：想要暂时隐藏某些文件的修改

# 添加到.gitignore但文件已被跟踪
git update-index --skip-worktree 文件名

# 恢复跟踪
git update-index --no-skip-worktree 文件名

# 查看被忽略的文件
git ls-files -v | grep ^S

问题18：工作区很乱，想要重新开始

# 丢弃所有未提交的修改
git reset --hard HEAD
git clean -fd

# 或者重新克隆仓库
cd ..
rm -rf 项目文件夹
git clone https://github.com/user/repo.git

问题19：想要把多个提交合并成一个

# 使用交互式rebase
git rebase -i HEAD~3

# 在编辑器中：
# pick 第一个提交
# squash 第二个提交
# squash 第三个提交

# 保存退出，然后编辑合并后的提交信息

问题20：配置了SSH但还是要输入密码

# 检查SSH密钥是否添加到ssh-agent
ssh-add -l

# 如果没有，添加密钥
ssh-add ~/.ssh/id_rsa

# 测试SSH连接
ssh -T git@github.com

# 确保远程URL使用SSH格式
git remote set-url origin git@github.com:username/repo.git

问题21：想要找回删除的分支

# 查看所有引用的历史（包括删除的分支）
git reflog

# 找到删除前分支的commit-id，然后恢复
git checkout -b 恢复的分支名 commit-id

问题22：子模块更新问题

# 初始化并更新所有子模块
git submodule update --init --recursive

# 更新子模块到最新版本
git submodule update --remote

# 克隆时同时克隆子模块
git clone --recursive https://github.com/user/repo.git

问题23：想要统计代码提交量

# 查看提交数量统计
git shortlog -sn

# 查看某个作者的提交
git log --author="作者名" --oneline

# 查看代码行数统计
git log --stat --author="作者名"

# 查看某个时间段的提交
git log --since="2024-01-01" --until="2024-12-31" --author="作者名"

10. 最佳实践

9.1 提交信息规范

好的提交信息格式：

类型(范围): 简短描述

详细描述（可选）

相关issue编号（可选）

常用类型：

  • feat: 新功能
  • fix: bug修复
  • docs: 文档更新
  • style: 代码格式调整
  • refactor: 重构
  • test: 测试相关
  • chore: 构建过程或辅助工具的变动

示例：

git commit -m "feat(auth): 添加用户登录功能

- 实现用户名密码验证
- 添加记住登录状态功能
- 集成第三方登录

Closes #123"

9.2 分支命名规范

feature/功能名称     # 新功能开发
bugfix/bug描述      # bug修复
hotfix/紧急修复     # 生产环境紧急修复
release/版本号      # 发布准备

示例：

  • feature/user-profile
  • bugfix/login-error
  • hotfix/payment-crash

9.3 工作流建议

  1. 频繁提交：小步快跑，频繁提交代码
  2. 有意义的提交：每次提交都应该是一个完整的功能点
  3. 先拉取再推送：推送前先pull最新代码
  4. 代码审查：重要修改通过Pull Request进行代码审查
  5. 备份重要分支：定期推送到远程仓库

9.4 .gitignore文件

创建.gitignore文件来忽略不需要版本控制的文件：

# 依赖目录
node_modules/
vendor/

# 构建产物
dist/
build/
*.min.js

# 日志文件
logs/
*.log

# 临时文件
tmp/
*.tmp
*.swp

# 环境配置
.env
.env.local

# IDE文件
.vscode/
.idea/
*.suo
*.user

# 操作系统文件
.DS_Store
Thumbs.db

9.5 团队协作建议

  1. 统一开发环境：使用相同的Git配置和工具
  2. 定期同步：每天开始工作前先拉取最新代码
  3. 分支保护：对主分支设置保护规则
  4. 代码审查：建立代码审查流程
  5. 文档维护：及时更新项目文档

11. 企业级和大型开源项目的Git工作流

11.1 企业级Git工作流

GitFlow工作流（适合版本发布驱动的项目）

分支结构：

master     ←────────←────────← (生产环境，稳定版本)
  ↑                            
release/v1.1 ←──←──←──←──←      (发布准备分支)
  ↑              ↑
develop   ←─←─←─←─┴──←──←──     (开发主分支)
  ↑       ↑
feature/  feature/  hotfix/   (功能分支和热修复分支)
login     payment    critical-bug

实际操作流程：

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

# 2. 开发功能
git add .
git commit -m "feat: 添加用户资料编辑功能"

# 3. 完成功能后合并到develop
git checkout develop
git pull origin develop
git merge feature/user-profile
git push origin develop

# 4. 准备发布时创建release分支
git checkout develop
git checkout -b release/v1.2.0

# 5. 在release分支进行最后的bug修复
git commit -m "fix: 修复发布前的小问题"

# 6. 发布：合并到master和develop
git checkout master
git merge release/v1.2.0
git tag v1.2.0
git push origin master --tags

git checkout develop
git merge release/v1.2.0
git push origin develop
GitHub Flow（适合持续部署的项目）

简化流程：

master ←──←──←──←──←── (主分支，随时可部署)
   ↑      ↑      ↑
feature/ feature/ feature/
 login    payment  dashboard

操作流程：

# 1. 从master创建功能分支
git checkout master
git pull origin master
git checkout -b feature/api-optimization

# 2. 开发并推送
git add .
git commit -m "perf: 优化API响应时间"
git push origin feature/api-optimization

# 3. 创建Pull Request进行代码审查

# 4. 审查通过后合并到master
# （通过GitHub界面或命令行）
git checkout master
git pull origin master
git merge feature/api-optimization
git push origin master

# 5. 删除功能分支
git branch -d feature/api-optimization
git push origin --delete feature/api-optimization

11.2 大型开源项目的实践

Linux内核项目的邮件驱动工作流

特点：

  • 通过邮件提交补丁
  • 严格的代码审查流程
  • 维护者负责集成代码
# 1. 生成补丁
git format-patch -1 HEAD

# 2. 发送补丁邮件
git send-email 0001-your-patch.patch
Kubernetes项目的协作模式

分支策略：

  • master：主开发分支
  • release-X.Y：发布分支
  • feature：功能分支

贡献流程：

# 1. Fork项目到自己的账户

# 2. 克隆自己的fork
git clone https://github.com/你的用户名/kubernetes.git
cd kubernetes

# 3. 添加上游仓库
git remote add upstream https://github.com/kubernetes/kubernetes.git

# 4. 创建功能分支
git checkout -b feature/improve-scheduler

# 5. 开发功能
# ... 编写代码 ...

# 6. 提交
git add .
git commit -s -m "scheduler: improve node selection algorithm

This commit improves the node selection algorithm by...

Fixes #12345"

# 7. 推送到自己的fork
git push origin feature/improve-scheduler

# 8. 创建Pull Request

# 9. 根据审查意见修改
git add .
git commit --amend
git push -f origin feature/improve-scheduler

11.3 代码审查流程

Pull Request最佳实践

PR标题格式：

类型(范围): 简短描述

例如：
feat(auth): 添加OAuth2支持
fix(api): 修复用户权限检查bug
docs(readme): 更新安装说明

PR描述模板：

## 修改内容
简要描述这个PR的主要修改

## 修改原因
解释为什么需要这个修改

## 测试
- [ ] 单元测试已通过
- [ ] 集成测试已通过
- [ ] 手动测试已完成

## 相关Issue
Fixes #123
Related to #456

## 截图（如果适用）
[添加截图或GIF]

## 检查清单
- [ ] 代码遵循项目规范
- [ ] 已添加必要的测试
- [ ] 文档已更新
- [ ] 没有破坏性变更
代码审查指南

审查者应该检查：

  1. 功能正确性：代码是否实现了预期功能
  2. 代码质量：是否遵循编码规范
  3. 性能影响：是否有性能问题
  4. 安全性：是否存在安全漏洞
  5. 测试覆盖：是否有足够的测试
  6. 文档完整性：是否需要更新文档

审查命令：

# 检出PR分支进行本地测试
git fetch origin pull/123/head:pr-123
git checkout pr-123

# 查看修改内容
git diff master..pr-123

# 运行测试
npm test

# 检查代码风格
npm run lint

11.4 发布管理

语义化版本控制

版本号格式： MAJOR.MINOR.PATCH

  • MAJOR：不兼容的API修改
  • MINOR：向后兼容的功能性新增
  • PATCH：向后兼容的问题修正

示例：

# 创建发布分支
git checkout -b release/v2.1.0

# 更新版本号
npm version minor  # 自动更新package.json并创建tag

# 推送发布
git push origin release/v2.1.0
git push origin v2.1.0
自动化发布流程

GitHub Actions示例：

name: Release
on:
  push:
    tags:
      - 'v*'
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Setup Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '16'
      - name: Install dependencies
        run: npm ci
      - name: Run tests
        run: npm test
      - name: Build
        run: npm run build
      - name: Publish to npm
        run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

11.5 团队协作规范

分支命名规范
# 功能分支
feature/JIRA-123-user-authentication
feature/add-payment-gateway

# Bug修复分支
bugfix/JIRA-456-login-error
hotfix/critical-security-patch

# 发布分支
release/v1.2.0
release/2024-Q1

# 实验分支
experiment/new-ui-framework
poc/microservices-migration
提交信息规范（Conventional Commits）
# 格式
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

# 示例
feat(auth): 添加Google OAuth登录支持

支持用户通过Google账户登录系统，包括：
- OAuth2认证流程
- 用户信息获取
- 账户关联功能

Closes #123
Breaking Change: 需要配置GOOGLE_CLIENT_ID环境变量
多人协作最佳实践
  1. 每日同步
# 每天开始工作前
git checkout master
git pull origin master
git checkout your-feature-branch
git rebase master
  1. 小而频繁的提交
# 好的提交
git commit -m "feat: 添加用户头像上传功能"
git commit -m "test: 添加头像上传的单元测试"
git commit -m "docs: 更新用户管理API文档"

# 避免的提交
git commit -m "各种修改"
git commit -m "修复bug"
  1. 使用分支保护规则
# GitHub分支保护设置
master分支要求：
- 通过状态检查
- PR审查（至少1人）
- 最新分支要求
- 管理员也需要遵循规则
  1. 定期清理分支
# 删除已合并的本地分支
git branch --merged master | grep -v master | xargs git branch -d

# 删除远程已删除的本地追踪分支
git remote prune origin

结语

Git是现代软件开发的必备工具，从个人项目到企业级应用，从小团队到大型开源社区，Git都提供了强大而灵活的版本控制解决方案。

学习建议：

  1. 渐进式学习：从基础命令开始，逐步掌握高级功能
  2. 实战练习：在真实项目中应用Git，通过实践加深理解
  3. 团队协作：参与开源项目或团队开发，体验Git的协作威力
  4. 持续改进：根据项目需求调整Git工作流，没有完美的流程，只有适合的流程

核心思想：

Git不仅仅是一个工具，更是一种思维方式：

  • 版本化思维：将变更作为历史记录来管理
  • 分支化思维：并行开发，独立演进，最终融合
  • 协作化思维：通过规范和流程实现高效团队协作

无论你是刚开始学习编程的新手，还是经验丰富的开发者，掌握Git都将是你职业生涯中最有价值的投资之一。每一次commit都是你成长的记录，每一次merge都是团队协作的体现，每一个分支都是创新的可能。

常用 Git 命令使用教程
weixin_30344995的博客
10-19 832
下面整理一下自己在开发过程中经常使用到的 Git 命令。使用 GUI 工具的同学，也可以对照起来看看。 Git 配置 1. 在安装完成 Git 后，开始正式使用前，是需要有一些全局设置的，如用户名、邮箱。 设置的主要命令是git config: 1 2 git config --global user.name "your name" // 设置全局用户名...
企业级开源版本管理系统GIT分析
sunbeacher的博客
04-17 1303
Git、GitHub、TortoiseGit等各种概念容易混淆，本文讲解这些系统的概念、用途和范围，以及如何基于开源软件搭建版本管理系统。
Git操作命令
weixin_33873846的博客
04-18 203
初始化配置 # 配置使用git仓库的人员姓名 git config --global user.name "Your Name Comes Here" # 配置使用git仓库的人员email git config --global user.email [email protected] # 配置到缓存 默认...
git完整学习指南
最新发布
qq_48107900的博客
06-25 966
全面且新手友好的版本控制系统教程，涵盖从基础概念到高级应用的完整知识体系。
Git 教程详解
GG Bond 的博客
08-10 717
Git 的使用教程！！！
git教程详解（一）
牧码心
11-27 872
git是一个很好的分布式版本管理工具，在git中，版本库又叫仓库，英文名为repository，可以简单的理解为本地的一个目录，用git进行管理，目录内的文件git进行删除，修改等操作时，git都可以跟踪，从而记录仓库的操作历史。
Git 教程（详细版）
name_sakura的博客
04-26 1万+
文章目录1.Git简介1.1 Git诞生1.2 集中式vs分布式1.3 安装Git在Linux上安装Git在Windows上安装Git1.4 创建版本库1.5 把文件添加到版本库2.时光机穿梭2.1 修改并提交2.2 版本回退2.3 工作区和暂存区2.4 管理修改2.5 撤销工作区和暂存区的修改把工作区中的修改撤销把暂存区中的修改回退到工作区2.6 删除也是修改操作3.远程仓库3.1 GitHub中添加SSH Key3.2 添加远程库3.3 删除远程库3.4 从远程库克隆4.分支管理4.1 创建与合并分支4
基于Java核心技术的企业级开源项目zheng设计源码
02-22
该项目是一款基于Java核心技术的企业级开源项目zheng，采用Java、JavaScript、CSS和HTML等多语言开发，共计627个文件。其中，Java源代码文件占198个，XML配置文件122个，属性文件100个，JSP文件67个，JavaScript文件...
Git详细使用教程文档
04-27
GitHub主要侧重于开源项目，而GitLab则允许用户创建私有仓库，更适合个人和企业内部的项目管理。 安装Git非常简单，可以从官方网站(<https://git-scm.com/downloads>)下载对应操作系统的安装包，按照指引进行安装。...
掌握从GitHub拉取代码的详细指南-基于Git的操作教程
02-03
内容概要：本文详细介绍了从GitHub平台拉取项目代码的完整流程，包括Git软件的安装配置、SSH密钥对GitHub账户的安全认证绑定，以及如何使用Git命令对指定项目的克隆操作和现有项目的代码同步。每一个环节都配合具体...
Git入门详细教程
m0_50281408的博客
01-18 1432
版本控制是一种管理文件变化的系统，它可以跟踪文件的修改、添加和删除，并记录这些变化的历史。版本控制系统可以帮助团队协作开发，确保每个人都在同一个代码基础上工作，并且可以轻松地查看和恢复文件的不同版本。它还可以提供分支和合并功能，允许多个开发者并行地修改代码，并将这些修改合并到一个共同的代码库中。版本控制系统可以提高开发效率，减少错误，并且有助于保持代码库的整洁和可维护性。Git分支是在Git版本控制系统中用于并行开发和管理不同功能或版本的代码的重要概念。
Git超详细使用教程
weixin_45822310的博客
12-16 5198
Git超详细使用教程
Git 操作教程
高空的博客
08-16 2477
1.Git简介2.Git安装3.远程仓库准备工作4.创建版本库5.将本地仓库添加到远程仓库6.工作区和暂存区7.删除文件8.添加远程库9.问题解答
git详细使用教程
热门推荐
2401_88244350的博客
10-29 3万+
首相，你要明确说明一下，git是软件，是用来进行版本控制的软件，什么叫版本控制，举个例子吧，你在用word软件写论文的时候，同一篇论文你可能会保存好几个：“‘GAN网络应用初级版’”，”GAN网络应用中期版“，“GAN网络应用最终版”。而git要做的就是类似这种不同版本之间的管理与控制。
Git使用详细教程
weixin_30663391的博客
11-25 2万+
　一：Git是什么？ 　　Git是目前世界上最先进的分布式版本控制系统。 　　二：SVN与Git的最主要的区别？ 　　SVN是集中式版本控制系统，版本库是集中放在中央服务器的，而干活的时候，用的都是自己的电脑，所以首先要从中央服务器哪里得到最新的版本，然后干活，干完后，需要把自己做完的活推送到中央服务器。集中式版本控制系统是必须联网才能工作，如果在局域网还可以，带宽够大，速度够快，如果在互联...
Git使用教程（超详细！）
GottenZZP的博客
04-17 7154
Git使用教程，嘎嘎详细
git使用教程(超详细)-透彻理解git
yjy000的博客
01-06 5739
Git 是一个开源的分布式版本控制系统，用于高效地管理代码和文件的更改。它由于 2005 年开发，最初是为 Linux 内核的开发而设计的。Git 因其强大的功能、灵活性和性能而广泛用于软件开发、项目协作和版本管理。
Git教程（超详细，一文秒懂）
♚焕蓝·未来的博客
04-15 3万+
Git 是一个免费的、开源的分布式版本控制系统，可以快速高效地处理从小型到大型的各种项目。Git 易于学习， 占地面积小， 性能极快。 它具有廉价的本地库， 方便的暂存区域和多个工作流分支等特性。 其性能优于 Subversion、CVS、Perforce 和 ClearCase 等版本控制工具。
超详细的 Git 实战教程
muzidigbig的博客
04-09 3498
一：Git是什么？ Git是目前世界上最先进的分布式版本控制系统。 二：SVN与Git的最主要的区别？ SVN是集中式版本控制系统，版本库是集中放在中央服务器的，而干活的时候，用的都是自己的电脑，所以首先要从中央服务器哪里得到最新的版本，然后干活，干完后，需要把自己做完的活推送到中央服务器。集中式版本控制系统是必须联网才能工作，如果在局域网还可以，带宽够大，速度够快，如果在互联网下，如果网速...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值