git使用手册

一、git常用命令

1、初始化配置

初始化本地仓库：git init

克隆远程仓库到本地：git clone <仓库URL>

设置全局用户名：git config --global user.name "your name"

设置全局邮箱：git config --global user.email "your@email.com"

查看当前配置：git config --list

2、基本操作

查看工作区状态（未跟踪/已修改文件）：git status

将文件添加到暂存区（. 表示全部文件）git add <文件> 或 git add .

提交暂存区文件到本地仓库：git commit -m "提交信息"

修改最后一次提交（如补充信息或合并暂存变更）：git commit --amend

删除文件并从 Git 中移除（需提交）：git rm <文件>

 

重命名文件并跟踪变更：git mv <旧文件名> <新文件名>

3、分支管理

列出所有本地分支（* 表示当前分支）：git branch

创建新分支：git branch <分支名>

切换分支：git checkout <分支名> 或 git switch <分支名>

创建并切换到新分支：git checkout -b <分支名>

合并指定分支到当前分支：git merge <分支名>

删除本地分支（-D 强制删除）：git branch -d <分支名>

删除远程分支：git push origin --delete <分支名>

4、远程仓库操作

添加远程仓库地址（别名通常为 origin）：git remote add origin <仓库URL>

查看远程仓库地址：git remote -v

推送本地分支到远程仓库：git push origin <分支名>

拉取远程分支并合并到当前分支（等价于 fetch + merge）：git pull origin <分支名>

下载远程分支更新（不自动合并）：git fetch origin

首次推送本地分支并设置上游关系：git push --set-upstream origin <分支名>

5、查看历史与差异

查看提交历史（--oneline 简化显示）：git log

以图形化显示分支合并历史：git log --graph --all

查看某次提交的详细变更：git show <提交哈希>

查看工作区与暂存区的差异：git diff

查看暂存区与最新提交的差异：git diff --cached

比较当前分支与指定分支的差异：git diff <分支名>

6、撤销与回滚

丢弃工作区修改（恢复为暂存区或最新提交状态）：git restore <文件>

将文件从暂存区移回工作区（不丢弃修改）：git restore --staged <文件>

回退到指定提交（保留工作区修改）：git reset <提交哈希>

　　　　--soft：仅移动 HEAD，保留暂存区和工作区。

　　　　--mixed（默认）：移动 HEAD 并重置暂存区。

　　　　--hard：完全回退（慎用，会丢失工作区修改）。

生成反向提交，撤销指定提交的变更（安全且保留历史）：git revert <提交哈希>

7、标签管理

列出所有标签：git tag

创建轻量标签（指向提交）：git tag <标签名>

创建附注标签（含元数据）：git tag -a <标签名> -m "描述"

推送单个标签到远程：git push origin <标签名>

推送所有标签到远程：git push origin --tags

8、高级操作

暂存当前工作区修改（用于临时切换分支）：git stash

恢复最新暂存并删除记录：git stash pop

将其他分支的提交应用到当前分支：git cherry-pick <提交哈希>

变基操作（将当前分支的提交“重新播放”到目标分支上，保持线性历史）：git rebase <分支名>

查看所有操作记录（包括已删除的提交，用于恢复）：git reflog

常用场景示例

首次提交代码

git init
git add .
git commit -m "Initial commit"
git remote add origin https://github.com/user/repo.git
git push -u origin main

撤销未提交的修改

git restore <文件>  # 丢弃工作区修改
git restore --staged <文件>  # 从暂存区移回

合并冲突解决

冲突文件会标记 <<<<<<<，手动编辑后执行：

git add <冲突文件>
git commit  # Git 会自动生成合并提交

二、git代码流转

在 Git 中，工作区（Working Directory）、暂存区（Stage/Index）、本地仓库（Local Repository） 和 远程仓库（Remote Repository） 是代码管理的四个核心区域，它们通过特定的操作相互关联，形成代码的流转路径。以下是它们的详细关系及代码流转过程：

---

1. 核心区域定义

区域	作用
工作区	开发者直接编辑的文件目录（即项目文件夹），包含未跟踪和已修改的文件。
暂存区	临时存储区，记录“下次提交时包含哪些修改”（通过 git add 添加）。
本地仓库	存储所有提交历史的数据库（.git 目录），包含完整的版本控制信息。
远程仓库	托管在服务器上的代码库（如 GitHub/GitLab），供团队协作使用。

---

2. 代码流转路径

代码从创建到共享的完整流程如下：

（1）工作区 → 暂存区

• 操作：git add <文件> 或 git add .
• 作用：将工作区的修改标记为“准备提交”，存入暂存区。
• 示例：

• # 修改文件后
  git add main.py          # 将 main.py 的修改加入暂存区
  git add .                # 将所有修改加入暂存区

• 关键点：
  • 暂存区是提交前的“快照准备区”。
  • 多次 git add 会覆盖暂存区的对应文件状态。

（2）暂存区 → 本地仓库

• 操作：git commit -m "提交信息"
• 作用：将暂存区的修改永久保存到本地仓库，生成一个唯一的提交哈希（commit hash）。
• 示例：

• git commit -m "修复登录按钮样式"

• 关键点：
  • 提交后，暂存区会被清空（除非使用 git commit -a 自动暂存并提交）。
  • 每次提交代表一个“版本快照”，可通过 git log 查看历史。

（3）本地仓库 → 远程仓库

• 操作：git push origin <分支名>
• 作用：将本地仓库的提交推送到远程仓库的对应分支。
• 示例：

• git push origin main      # 推送本地 main 分支到远程

• 关键点：
  • 首次推送需设置上游分支：git push -u origin main。
  • 推送前需通过 git pull 同步远程变更，避免冲突。

（4）远程仓库 → 本地仓库

• 操作：git pull origin <分支名>（等价于 git fetch + git merge）
• 作用：拉取远程仓库的最新提交并合并到本地分支。
• 示例：

• git pull origin main      # 拉取远程 main 分支并合并

• 关键点：
  • 如果远程有更新而本地未拉取，直接推送会失败（需先 pull）。
  • 使用 git fetch 仅下载更新，不自动合并，适合手动处理冲突。

（5）工作区 ↔ 暂存区/本地仓库的撤销操作

• 撤销工作区修改：

• git restore <文件>       # 丢弃工作区修改（恢复为暂存区或最新提交状态）

• 撤销暂存区修改：

• git restore --staged <文件>  # 将文件从暂存区移回工作区（不丢弃修改）

• 回退本地提交：

• git reset HEAD~1         # 回退到上一次提交（保留修改）
  git reset --hard HEAD~1  # 强制回退（丢弃所有修改）

3. 完整代码流转示例

假设开发一个新功能：

1. 修改文件（工作区）：

   echo "print('Hello Git')" >> app.py

2. 添加到暂存区：

   git add app.py

3. 提交到本地仓库：

   git commit -m "添加 Hello Git 输出"

4. 推送到远程仓库：

   git push origin main

5. 其他成员拉取更新：

   git pull origin main

---

4. 区域间关系图解

工作区 (Working Directory)│↓ git add
暂存区 (Stage/Index)│↓ git commit
本地仓库 (Local Repository)│↓ git push
远程仓库 (Remote Repository)│↑ git pull

 

---

5. 关键注意事项

1. 暂存区的意义：
   • 允许分批次提交（例如先提交代码，再提交配置文件）。
   • 避免一次性提交过多无关修改。
2. 推送前的同步：
   • 推送前必须 git pull，否则可能因远程更新导致冲突。
3. 冲突处理：
   • 如果 pull 或 merge 时发生冲突，需手动编辑文件后执行 git add 和 git commit。
4. 分支隔离：
   • 不同分支的代码流转独立，通过 git checkout <分支名> 切换。

---

通过理解这四个区域的关系和代码流转路径，可以更高效地使用 Git 进行版本控制，避免误操作和数据丢失。

三、git代码分支模型

在项目开发过程中使用 Git 的方式常见的有：

集中式工作流

所有修改都提交到 Master 这个分支。比较适合极小团队或单人维护的项目，不建议使用这种方式

 功能开发工作流

功能开发应该在一个专门的分支，而不是在 master 分支上。适用于小团队开发

 GitFlow工作流

公司中最常用于管理大型项目。为功能开发、发布准备和维护设立了独立的分支，让发布迭代过程更流畅

 Forking工作流

在 GitFlow 基础上，充分利用了 Git 的 Fork 和 pull request 的功能以达到代码审核的目的。一般用于跨团队协作、网上开源项目

 各分支功能介绍

 主干分支 master

主要负责管理正在运行的生产环境代码，永远保持与正在运行的生产环境完全一致。为了保持稳定性一般不会直接在这个分支上修改代码，都是通过其他分支合并过来的。

开发分支 develop

主要负责管理正在开发过程中的代码。一般情况下应该是最新的代码。

功能分支 feature

为了不影响较短周期的开发工作，一般把中长期开发模块，会从开发分支中独立出来。 开发完成后会合并到开发分支。

准生产分支（预发布分支） release

较大的版本上线前，会从开发分支中分出准生产分支，进行最后阶段的集成测试。该版本上线后，会合并到主干分支。生产环境运行一段阶段较稳定后可以视情况删除。

bug 修理分支 hotfix

主要负责管理生产环境下出现的紧急修复的代码。 从主干分支分出，修复完毕并测试上线后，并回主干分支和开发分支。并回后，视情况可以删除该分支。