黑马程序员视频地址：
部分标题前有数字，代表学习顺序
安装
下载地址：
安装时除路径外全都默认下一步即可
配置
❶查看版本号
1.打开bash终端（git专用）
2.输入命令：git -v
❷配置用户信息
配置用户名和邮箱，每次提交时交代自己的身份
如果不同仓库需要设置不同用户昵称与邮箱，可以去掉--global，只配置当前文件
#配置用户名
git config --global user.name "用户昵称"
#配置邮箱
git config --global user.email "用户邮箱"配置完成可以输入以下命令查看配置列表
git config --list提示：
1.不能完全显示内容，可以按回车键显示下一行，直到显示END
2.显示END之后，可以按Q键退出
❸新建仓库
1.在本地文件夹中创建仓库（创建仓库会在该文件夹下产生一个名为.git的隐藏文件夹）
git init2.下载别人的仓库
⓭忽略文件
让git忽略配置的文件
在项目根目录下创建".gitignore"文件，将相忽略的文件夹名称或文件名称输入进去即可
*是通配符：匹配任意字符
该文件需要一起上传
# 忽略 npm 下载的第三方包
node_modules
# 忽略分发文件夹
dist
# 忽略 VSCode 配置文件
.vscode
# 忽略秘钥文件
*.pem
*.cer
# 忽略日志文件
*.log概念
❹git的三个区域
工作区：实际开发时操作的文件夹
暂存区：保存之前的准备区域（暂存改动过的文件）
版本库：提交并保存暂存区中的内容，产生一个版本快照
❽文件状态
| 文件状态 | 概念 | 场景 |
|---|---|---|
| 未跟踪（U） | 从未被 Git 管理过 | 新文件 |
| 新添加（A） | 第一次被 Git 暂存 | 之前版本记录无此文件 |
| 未修改（""） | 三个区域统一（提交到版本库后） | 提交保存后 |
| 已修改（M） | 工作区内容变化 | 修改了内容产生 |
查看文件状态
结果：第一列是在暂存区的状态，第二列是在工作区的状态
#加上-s看简略信息，去掉则查看详细信息
git status -s使用
新增
❺移入暂存区
将工作区内容放到暂存区
目标文件均指相对于（存放仓库的）项目首页的相对路径
#暂存指定文件
git add 目标文件
#暂存所有改动的文件
git add .❻查看暂存区
查看当前项目暂存区内容
内容过多显示不全时可以按回车键继续显示，也可以直接按Q键退出
git ls-files❼移入版本库
将暂存区保存到版本库中
git commit -m "注释说明"覆盖
❾覆盖工作区
暂存区文件覆盖工作区文件
注意：完全确认覆盖时使用
git restore 目标文件❿移除暂存区
从暂存区移除文件
git rm --cached 目标文件全部移除
git rm --cached -r .版本库
⓫查看版本库
查看已经提交到版本库的内容
#基于当前版本库查看以提交的版本库（去掉 --oneline可以查看详细信息）
git log --oneline
#查看所有时间段的版本库
git reflog --oneline⓬回退版本
回退版本
git 是通过从右向左依次映射的工作方式来删除内容，
例如：使用暂存区的内容比对工作区的内容进行删除
如果：先使用第三个模式删除了暂存区的内容，再使用第二个模式会无法删除工作区的内容
#工作区与暂存区中比选中的版本多的内容不会被清除，会被转化为未跟踪状态（U）
git reset --soft 版本号
#工作区与暂存区原本的内容会被完全替换成选中的版本
git reset --hard 版本号 （一般选择这个）
#工作区与第一种一样（多余保留），暂存区与第二种模式一样（完全替换）
# --mixed 写不写一样效果
git reset --mixed 版本号
分支
⓮创建与切换
git中有一个默认指针：master（可能有其他名字）和一个HEAD指针
master指针所在路为主分支，master永远指向最近一次保存的主线内容
HEAD指针所指向的版本会显示在工作区与暂存区
创建分支相当于创建支路，不会影响主分支master
创建与切换指针命令
#创建分支
git branch 分支名
#切换分支
git checkout 分支名
#查看本地分支
git branch
#创建并立即切换分支
git checkout -b 分支名⓯合并与删除
步骤：
1.切回要合并的分支上
2.合并其他分支过来
3.删除合并后的分支指针
#在当前分支下合并指定分支
git merge 指定分支
#删除合并后的分支指针（在任意分支下都能进行）
git branch -d 指定分支如果此时再合并分支content，则会按照产生的先后顺序排列（而不是合并的先后），合并之后，会再比较content最新版本与主分支最新版本的差异并合并成一个新的版本
⓰合并冲突
原因：不同分支中，对同一个文件的同一部分修改，Git 无法干净的合并，产生合并冲突
VSCode会让你做出选择
选择后需要重新提交到版本库
远程仓库
推送及删除
1.注册第三方托管平台账号，如gitee、github等
2.创建一个远程仓库，并复制远程仓库git地址
3.在本地git仓库添加远程仓库原点地址
#添加远程仓库（可添加多个，一般只添加一个）
git remote add 远程仓库别名 远程仓库地址
#删除已添加的远程仓库
git remote remove 远程仓库别名
#查看远程仓库地址
git remote -v注意：使用git remote add 时，需要先新建一个仓库/克隆仓库
4.推送本地仓库版本记录到远程仓库
#如果本地分支名与远程分支名一样，可以省略一个
git push -u 远程仓库别名 本地分支名:远程分支名
#建立通道后可以简写git push
#-u 是 --set-upstream 的缩写。
#当你执行 git push -u 远程仓库别名 本地分支名:远程分支名 时，
#它不仅会将本地分支的内容推送到指定的远程分支，
#还会为本地分支设置上游分支。
#上游分支可以理解为本地分支在远程仓库中对应的分支，Git 会记住这种关联关系。5.第一次推送会让你输入账号密码，如果要切换账号，可以按照下图操作进行删除
注意：gicode平台需要输入令牌而非密码
克隆
克隆远程仓库到本地
会在执行命令的文件夹下再生产一个与远程仓库名同名的文件夹
git clone 远程仓库地址拉取
拉取
多人开发，别人更新远程仓库，本地已有该仓库的成员可以通过拉取获取最新版本
#该命令等价于：git fetch 和git merge
git pull 远程仓库别名 远程分支名:本地分支名
#合并没有关系的记录？
git pull --rebase 远程仓库别名 分支名在从远程仓库拉取本地没有的文件后，是否需要再次提交到本地版本库，取决于拉取操作（git pull）的结果
情况一：拉取过程中没有发生冲突
当执行 git pull 命令时，如果远程仓库的更新与本地代码没有冲突，Git 会自动完成合并操作，将远程的更新合并到本地分支，并且更新本地的提交历史。此时，本地仓库已经包含了最新的代码状态，你可以直接执行 git push 命令将本地代码推送到远程仓库，而无需再次手动提交
情况二：拉取过程中发生冲突
若在 git pull 过程中出现冲突，意味着远程仓库和本地仓库的修改存在矛盾，Git 无法自动完成合并，需要你手动解决冲突
CR、LF问题
以下回答来自AI
报错：
$ git add .
warning: in the working copy of 'package-lock.json', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'package.json', LF will be replaced by CRLF the next time Git touches it
原因:
出现的这些警告信息表明 Git 检测到工作副本中的 package-lock.json 和 package.json 文件使用的是 LF（Unix/Linux 换行符），而在 Git 后续处理这些文件时，会将换行符替换为 CRLF（Windows 换行符）
机理：
core.autocrlf 值为true时，git会在提交时将所有文件的crlf转化成lf，再读取时又会将所有的lf转化成crlf，导致上述两个文件里的lf被转成crlf
解决方案
1.将core.autocrlf值改成false：直接不进行转换
2.添加.gitattributes文件，在里面设置指定的格式（可部分设置，也可以全部设置）
注意：第二章方法与第一种方法的配置冲突时，会优先执行第二种，即第二种的优先级高
方法二：配置.gitattributes文件：
代码1：
package-lock.json text eol=lf
package.json text eol=lf上述配置的含义是：
package-lock.json 和 package.json 被指定为文本文件（text）。
eol=lf 明确表示这些文件在提交和检出时都使用 LF 行尾符。无论 core.autocrlf 的配置如何，Git 都会遵循 .gitattributes 文件中的规则来处理这两个文件的行尾符
代码2：全部禁止转换（与方法一作用相同，但优先级高）
# 对所有文件禁用行尾符转换
* -text
代码详细解释
1.代码： package-lock.json text eol=lf
*
含义：这是一个通配符，表示匹配项目中的所有文件。也就是说，这条规则会应用到项目里的每一个文件上。
示例：无论文件是 .js、.css、.txt 还是其他类型，只要在当前项目仓库中，都会受到该规则的影响。
text=auto
含义：text=auto 让 Git 自动判断文件是否为文本文件。Git 会根据文件的内容特征来进行判断，例如，如果文件包含大量可打印的 ASCII 字符，且没有出现一些二进制文件特有的控制字符模式，Git 就会将其识别为文本文件；反之，则判定为二进制文件。
作用：只有当 Git 把文件识别为文本文件时，后续的 eol 规则才会生效。对于被判定为二进制文件的，Git 不会对其行尾符进行处理。
eol=lf
含义：eol 是 “End of Line” 的缩写，即行尾符的意思。eol=lf 明确指定了文本文件的行尾符使用 LF（换行符，\n）。
作用：当 Git 依据 text=auto 判断文件为文本文件后，在提交和检出文件时，会确保该文件使用 LF 作为行尾符。如果文件原本使用的是 CRLF（回车换行符，\r\n），提交时会将其转换为 LF 存储到版本库中；检出时，也会保证文件以 LF 行尾符存在于工作目录。
综合示例
假设项目中有一个 script.js 文件，其行尾符原本是 CRLF。当 .gitattributes 文件中有 * text=auto eol=lf 规则时：
提交时：Git 会根据 text=auto 判定 script.js 为文本文件，然后将文件中的 CRLF 行尾符转换为 LF 后再存储到版本库。
检出时：从版本库检出 script.js 文件到工作目录时，文件会保持 LF 行尾符。
这条规则通常用于确保项目中的所有文本文件统一使用 LF 行尾符，避免因不同操作系统默认行尾符不同而产生的问题，方便跨平台协作开发
2.代码：* -text
-text
text 在 Git 里用于标识文件是否作为文本文件处理。而 -text 前面的 - 是一个否定符号，-text 的意思是告诉 Git 不要把这些文件当作文本文件处理，而是将它们视为二进制文件。
行尾符处理
Git 对于文本文件和二进制文件的行尾符处理方式不同。当文件被标记为文本文件时，Git 会根据 core.autocrlf 配置或者 .gitattributes 文件中其他关于行尾符的规则（如 eol=lf 或 eol=crlf）对文件的行尾符进行转换。但当使用 * -text 规则后，Git 会把所有文件都当作二进制文件，从而不会对文件的行尾符进行任何转换操作，文件会保留其原始的行尾符格式。
例如，你有一个项目，里面的 code.js 文件原本使用的是 CRLF 行尾符，使用 * -text 规则后，无论你是提交这个文件到版本库，还是从版本库检出该文件到本地工作目录，code.js 文件的行尾符都会保持为 CRLF 不变。
避免不必要的差异
在跨平台开发时，不同操作系统默认的行尾符不同（Windows 是 CRLF，Unix/Linux 和 macOS 是 LF），如果不统一处理行尾符，可能会导致每次提交代码时出现大量因行尾符转换引起的文件差异，使版本控制记录变得混乱。使用 * -text 规则可以避免这种情况，因为它让 Git 不进行行尾符转换，从而减少了因行尾符不同而产生的不必要差异。
与其他规则的对比
和 * text=auto eol=lf 规则相比，* text=auto eol=lf 是让 Git 先自动判断文件是否为文本文件，对于判定为文本文件的，会统一将行尾符转换为 LF；而 * -text 是直接让 Git 把所有文件都当作二进制文件，不进行行尾符的转换，更强调保留文件原始的行尾符状态。