动机

• 不小心把正确的代码删了
• 写错了，怎么回到之前的版本
• 多个人怎么共同开发同一个项目
• 这个功能之前好好的，我到底改了啥
• 我想临时实验一个新功能

安装

• windows：从官网 https://git-scm.com/install/ 下载安装
• mac：自带 git，也可以从官网 https://git-scm.com/install/ 下载安装
• linux：使用命令 sudo apt-get install git 安装

配置

配置命令

git config -l                     # 查看当前是生效的所有配置
git config KEY                     # 查看当前生效的某个具体配置项 KEY 的值
git config [--SCOPE] KEY VALUE     # 设置/更新配置项 KEY 的值

配置范围 SCOPE

• worktree：仅对当前工作树生效
• local：【常见】【默认】仅对当前仓库有效
• global：【常见】对当前用户的所有仓库有效
• system：对所有用户有效

优先级从到到低：worktree > local > global > system

常见配置

• user.name：【必配】配置用户名。后续提交会使用该用户名
• user.email：【必配】配置邮箱。后续提交会使用该邮箱
• user.name：【必配】配置用户名。后续提交会使用该用户名
• core.editor：配置默认的文本编辑器
• core.ignorecase：配置是否忽略文件名的大小写，默认是 true，即忽略大小写
• init.defaultbranch：配置初始化后的默认分支名

git config --global user.name "wangchong1118"
git config --global user.email "wangchong1118@126.com"
git config --global core.editor "code"
git config --global core.ignorecase false
git config --global init.defaultbranch "main"

初始化

要对一个目录使用 git 进行版本管理，必须先将该目录设置为 git 仓库

使用 git init 命令初始化一个新的 git 仓库

该命令会在当前目录下创建一个 .git 目录，该目录就是 git 仓库，里面记录了仓库的所有信息。该目录不可删除，一旦删除，该仓库就不存在了

项目忽略文件 .gitignore

仓库中某些文件是「个人专属」不需要的文件排除，不会在团队间共享，可以使用 .gitignore 文件将不需要的文件在提交仓库是自动排除掉

提交

每一次提交就相当于将当前目录下的所有文件进行「拍照」，「照片」会保存在 git 仓库中

「拍照」的主要目的，是为了将来可以在不同的「照片」之间进行比较和恢复

「照片」的具体位置在 .git/objects 的目录下

如何提交

提交分为两步：

1. 【可选】查看当前 git 状态

   git status

2. 将更新的文件暂存起来

   git add <file1> <file2>        # 暂存指定的文件
   git add .                    # 暂存当前项目目录及子目录下的所有文件

3. 将暂存的内容一起提交

   git commit # 会自动打开默认的文本编辑器，在编辑器中编写提交信息，保存后自动完成提交
   git commit -m "提交信息"        # 直接在命令行中直接编写提交信息，直接完成提交，不打开文本编辑器

术语：

• 工作区：真实的工作文件
• 暂存区：git add 命令暂存起来的文件

提交信息编写规范

提交信息修改

git commit -amend

该命令通常用于修改最新的提交消息

所以使用该命令时，要确保自己所在的位置在最新的位置

最佳实践 1：

1. 编与提交消息时，尽量不要犯错
2. 提交后，立即审核提交消息，发现消息错误，立即通过上面的命令修复

最佳实践 2：让 AI 编写提交消息，审核后发布

回滚某个提交

git restore --source COMMIT_ID .    # 将指定的提交覆盖到当前项目工作区

使用上述命令时，要确保工作区干净（暂存区没东西，工作区无更改）

工作区如果不干净怎么办？（暂存区没东西或者工作区有更改）

1. 先把目前状态保存到存储库

   git stash push -u -a

2. 工作区干净了，就可以做任何其他的事情

3. 如果要恢复工作区

   git stash list  # 【可选】列出所有的存储
   git stash pop    # 恢复上一次的存储，同时删除上一次的存储
   git stash pop <STASH_ID> # 恢复到指定ID的存储，同时删除该存储

分支

牢记一下两点：

• 分支是一个指针，指向一个快照
• HEAD 是一个指针，指向一个分支

提交 1 --> 提交 2 --> 提交 3

分支 1 --> 提交 3
HEAD --> 分支 1

简化后

提交 1 --> 提交 2 --> 提交 3 (*分支 1)

分支管理

分支基本操作：

1. 查看分支

   git branch

2. 分支重命名

   git branch -m <new-name>                # 重命名当前分支
   git branch -m <old-name> <new-name>     # 重命名指定分支

3. 创建分支

   git branch <branch-name>                # 创建一个新的分支，指针和当前分支相同
   git branch <branch-name> <commit-hash>     # 创建一个新的分支，指针指向指定的提交

4. 切换分支

   git switch <branch-name>    # 切换到指定分支
   git switch -                 # 切换到上一个分支，非常方便的在两个分支间来回切换
   git switch -c <branch-name>    # 创建并切换分支的快捷方式：

5. 删除分支

   git branch -d <branch-name>    # 删除指定分支
   git branch -D <branch-name>    # 强制删除指定分支

分支的基本生命周期

永远不能在主分支上直接改动，主分支永远保证功能的完整可用、可部署

1. 新需求：功能/bug修复/版本回滚/...

2. 新建分支：

   feature/*    - 新功能开发
   bugfix/*    - 缺陷修复
   hotfix/*    - 紧急生产修复
   release/*    - 版本发布
   chore/*        - 维护性任务
   docs/*        - 文档更新
   refactor/*    - 代码重构

3. 在分支上开发测试：可能产生多次提交
4. 合并到主分支
5. 主分支测试
6. 删除开发分支

分支常见问题

• 如何保留现场

  git stash -a                 # 保存当前工作区的修改到存储库
  # 切换分支工作...
  # 切回分支
  git stash list                 # [可选]查询当前存储库
  git stash pop <stash-id>     # 调用某个存储库恢复工作区，同时删除存储库
  # 如果存库是最后一个，可以省略 id

• 如何解决冲突：冲突必须手动解决，尤其是主分支的冲突

远程仓库

注册 github 账号

https://github.com 自行注册

SSH 链接通道配置

1. 本地生成密钥对

ssh-keygen -t ed25519 -C "注册 github 的邮箱地址" -f ~/.ssh/xxx_github_key

生成完后，到电脑的 ～/.ssh 目录朗可看到之前生成的两个文件：

xxx_github_key            # 私钥
xxx_github_key.pub        # 公钥

2. 到 github 配置公钥

登录 github 后，在 github 的地址 https://github.com/settings/keys 地址下自行配置

配置密钥的配对规则

flowchart LR
    PrivateKey1 <--> PublicKey1ForGithub
    PrivateKey2 <--> PublicKey2ForGithub
    PrivateKey1 <--> PublicKey1ForGitee
    PrivateKey3 <--> PublicKey3ForGitlab

1. 打开 ~/.ssh/config，没有就创建一个

2. 配置规则

   # 规则 1
   Host wyemail.github.com        # 当连接 git@wyemail.github.com 时会匹配到此规则
    HostName github.com        # 实际上链接发出的主机
    IdentityFile ~/.ssh/wyemail_github_key    # 使用的私钥文件
    User git # 固定写法
   
   # 规则 2
   Host a                            # 当连接 git@a 时会匹配到此规则
    HostName github.com            # 实际上链接发出的主机
    IdentityFile ~/.ssh/a_github_key    # 使用的私钥文件
    User git # 固定写法    
    
   上述 PrivateKey 与 PublicKey 的关系图中，一条双向连接线就对应此处的一个规则

仓库和别名

要和远程仓库同步，先得有远程仓库

1. 在 github 中创建一个远程仓库
2. 在本地仓库中添加远程仓库的别名

别名的常见操作

# 查看当前的远程仓库的别名
git remote            # 简要信息
git remote -v        # 详细信息

# 添加别名
git remote add 远程仓库别名 远程仓库ssh地址

# 修改别名
git remote rename 原别名 新别名

# 删除别名
git remote remove 要删除的别名

远程仓库与本地仓库之间的分支同步

push 命令：

  本地仓库                    远程仓库
   
   master --- git push ---> master
                              |

origin/master <-- 自动同步 --------|

# 将本地的某个分支推送到指定仓库
git push -u 远程仓库别名 本地分支名

细节说明：

• 如果远程没有相关分支，则在远程创建同名分支

• 推送完成后，会在本地创建远程跟踪分支

  • 跟踪分支自动命名：仓库别名/分支名，如 origin/master
  • 跟踪分支是只读的，它的目的在于同步远程分支
  • 推送完成后，会自动同步远程跟踪分支

• 由于使用了参数 -u 在跟踪分支创建后，会自动把本地分支 master 绑定到跟踪分支 origin/main

  • 后续仅需要使用 git push 即可推送当前的 master 分支

这样，就完成了本地到远程的同步

pull 命令：

  本地仓库                           远程仓库
   
   master
     ∧
     | git merge
     |                        

origin/master <------ git fetch ------ master

1. 使用 git fetch 命令

   git fetch 远程仓库别名 远程分支名

2. 使用 git merge 命令合并分支

   # 确保当前在对应的分支上
   git merge 本地跟踪分支名

这样，就完成了远程到本地的同步

使用 git pull 命令，可以一步替代上面的两步操作

git pull 远程仓库 远程分支

clone 命令：

当本地没有工程时，可以使用 git clone 操作快速完成远程仓库的下载

git clone [-b 分支名] 远程仓库地址 [本地想要保存的文件夹]

同步的三种情况

1. 情况一：远程快进
2. 情况二：本地快进

3. 情况三：出现冲突

   1. 获取远程代码：git fetch orgin master
   2. 本地进行合并，git merge origin/master，报错冲突
   3. 手动解决冲突
   4. 本地提交一次，git commit -m "xxxxx"
   5. 本地推送到远程，git push origin master

简单总结

1. 正常推送拉取，没问题什么也不管
2. 推送报错，进入第 3 步
3. 拉取有冲突，解决冲突重新提交，然后进入第 2 步

github flow

完整流程

sequenceDiagram
    participant A AS 开发者
    participant B AS 本地仓库
    participant C AS 远程仓库
    participant D AS 管理员
    
    A ->> B: 1. 拉取：master 分支
    B --> C: 从远程同步最新代码 
    A ->> B: 2. 开发：切换分支，多次提交
    A ->> C: 3. 推送：推送开发分支
    A ->> C: 4. 创建PR：base master
    D ->> C: 5. review：代码审查
    D ->> C: 6. 提交：提交合并到 master 分支
    D ->> C: 7. 删除：删除开发分支

开发者规范

1. master 分支只读
2. 基于最新的提交进行开发

管理员规范

1. master 分支只能通过 PR 来修改
2. PR 永远无冲突