目录
17.怎样配置Git，让提交之前运行代码检查工具，并且在测试失败时阻止提交
使用 git checkout
用途:切换到之前的某个提交
命令:git checkout [commit hash]
注意:这会让你的工作目录处于"分离HEAD"状态，你可以查看、编译、运行代码，甚至在这个状态下开始新的开发，但如果你想保留这些更改，建议在新分支上进行。
使用 git revert
用途:创建一个新的提交，这个提交是对指定。
提交的逆向操作。
命令: git revert [commit_hash]
注意:这是一种安全的方法，因为它不会改变项目历史。它特别适用于公共分支上的更改撤销，因为它不会重写历史。
使用 git reset
用途:将HEAD(和可能是当前分支)重置到之前的某个提交，并根据使用的选项处理工作录和暂存区。
命令
git reset --soft [commit hash]:回退到0某个提交，保留工作目录不变，将回退过程中的所有提交差异放入暂存区。
git reset --mixed [commit hash]:(黑。认)回退到某个提交，保留工作目录不变但不保留暂存区的更改。
git reset --hard [commit hash]:彻底退到某个提交，放弃所有工作目录和暂存区中的更改。
注意: git reset 尤其是带 --hard 选项的使用，应谨慎进行，因为它会丢失后续的更改。在共享或公共分支上，避免使用能重写历史的命令。
使用 git reflog 配合其他命令
用途:在误操作后找回丢失的提交
命令: git reflog 查看操作历史，找到要恢复的提交的引用，然后使用 git checkout或 gitreset 等命令恢复。
注意: git reflog 是一个强大的工具，可以帮助你找回因重置、rebase等操作而"丢失"的提交，
git stash 是一个非常有用的Git命令，用于临时保存当前工作目录和暂存区的更改，让你可以获得一个干净的工作状态。这个命令在多种情况下特别有用以下是一些典型的使用场景
1.切换分支
当你正在一个分支上工作，但需要临时切换到另一个分支处理一些事情，而当前的更改又不足以进行提交时， git stash 可以帮助你保存当前的工作进度。处理完其他分支的工作后，你可以回到原来的分支并应用(pop)之前保存的更改，继续之前的工作。
2.保持工作目录的干净
在进行一些操作(如合并、拉取更新等)需要一个干净的工作目录时，如果你有未完成的更改，可以使用git stash 来临时保存这些更改，完成操作后再恢复
3.保存未完成的工作
如果你正在进行一个复杂的功能开发或修复，但还没到一个合适的提交点， git stash 允许你保存当前的工作进度。这样你可以随时回到这个点，无需提交半成品代码到仓库。
4.实验性更改
当你想尝试一些实验性的更改，但不确定这些更改是否有效时，可以先用 git stash 保存当前状态，然后自由地进行尝试。如果实验失败，可以轻松地回滚到之前的状态。
使用 git stash 的常见命令
保存更改: git stash 或 git stash push,可选地加上消息 -m "message"来描述保存的内
容
查看列表: git stash list，查看当前保存的stash列表，
应用最近的更改: git stash pop，)
-次保存的更改并从stash列表中移除
应用特定的更改: git stash applystashain}，应用指定的stash，其中n是stash列表中的索引。
删除stash:git stash drop stasha{n}，
除指定的stash项。
要从Git中删除文件而不从文件系统(本地目录)中删除它，你可以使用 git rm 命令的 --cached 选项。这个选项告诉Git停止跟踪指定的文件，但不从工作目录中删除文件。这通常用于将文件添加到.gitignore 中，以防止将来错误地将其提交到仓库中。
命令示例
假设你有一个名为 example.txt 的文件，已经被Git跟踪，现在你想从Git仓库中删除它，但保留在本地文件系统中，你可以这样做
git rm --cached example.txt
这条命令会从当前的暂存区(索弓)中移除example.txt，但文件在你的工作目录中仍然存在。
后续步骤
更新 .gitignore: 在执行上述命令后，你可能想要将该文件或文件模式添加到.gitignore 文件中，以确保这个文件在未来的提交中不会被包含
echo "example.txt">> .gitignore
提交更改:移除文件操作和更新 .gitignore 文件后，你需要提交这些更改到你的仓库
git add .gitignore
git commit -m 'Stop tracking example.txt'
生成SSH密钥对是与Git仓库进行安全通信的重要步骤，特别是当你使用如GitHub、GitLab等服务时。SSH密钥对包括一个私钥和一个公钥。私钥保留在你的计算机上，不与任何人分享;公钥可以安全地添加到Git服务器上。以下是生成SSH密钥对的步骤:
1.打开终端
打开你的命令行工具，比如在Linux或Mac上的Terminal，或在Windows上的Git Bash。
2.生成SSH密钥对
运行以下命令来生成一个新的SSH密钥对
ssh-keygen -t rsa -b 4096 -C"your_emaildexamp
-t rsa 指定密钥类型为RSA，这是一种常用的加密算法。
-b 4096 指定密钥长度为4096位，这比默认的2048位更安全。
-c后面跟的是一个注释，用来标识这个密钥，通常是你的电子邮件地址。
3.指定保存密钥的位置
当系统询问你“Enter a fle in which to save thekey”(在哪个文件保存密钥)时，你可以直接按回车键接受默认文件位置(通常是 ~/.ssh/id_rsa)
4.设置密码短语(可选)
系统将要求你输入一个密码短语，用于加密你的私钥。这是可选的，但是为了增加安全性，建议设置。每次使用密钥时，都会要求输入这个密码短语。
5.检查SSH密钥
生成密钥后，可以在 ~/.ssh 目录下找到它们。使用ls~/.ssh 查看。你应该看到 id_rsa (私钥)和id_rsa.pub (公钥)
6.添加SSH公钥到Git服务器
将 id_rsa.pub 文件的内容复制到剪贴板。在大多数 Unix 系统中，你可以使用 cat~/.ssh/id_rsa.pub |pbcopy (MacOS)或cat ~/.ssh/id_rsa.pub |xclip (Linux)来做到这一点。
登录到你的Git服务器(如GitHub、GitLab等)，找到添加SSH公钥的地方，通常在用广设置的SSH密钥部分。粘贴你的公钥并保存。
7.测试SSH连接
最后，你可以测试与Git服务器的SSH连接是否成功:
ssh -T gitagithub.com
请将 github.com 替换为你使用的Git服务的主机名，如果一切设置正确，你应该看到一条欢迎消息。
使用SSH密钥
如果你的远程仓库支持SSH连接(如GitHubGitLab等)，你可以设置SSH密钥来避免每次推送时输入用户名和密码。
生成SSH密钥(如果你还没有):请参考前一个叵答中关于如何生成SSH密钥的步骤。
将SSH公钥添加到远程仓库:登录到你的Git服务
(如GitHub)，在用户设置中找到SSH和GPG密钥部分，添加你的公钥。
确保使用SSH URL:使用 git remote -v 检查你的远程仓库URL是否是SSH格式。如果不是，你可以用下面的命令更改它(以GitHub为例)
git remote set-url origin git@github.com:use
使用凭证存储器
对于使用HTTPS URL的仓库，你可以使用Git的凭证存储器来保存你的登录信息，
配置Git使用凭证存储器
1 git config --global credential,helper osxkey
这个命令会告诉Git使用macos的密钥链来存储凭证，这样你就不需要每次都输入用户名和密码了
第一次使用:在你下一次 git push 时，Git会要求你输入用户名和密码，但这会是最后一次需要手动输入。之后，这些信息会被保存在macoS的密钥链中，Git在之后的操作中会自动使用这些凭证
如果你发现 .gitignore 文件似乎没有按预期工作,即Git仍然跟踪那些应该被忽略的文件或目录，这可能是由于这些文件已经被Git跟踪(即已经被加入到了索引中)。.gitignore 文件只能阻止未被跟踪的文件被自动加入到索引中，对于已经被跟踪的文件，它不会有任何效果。以下是解决.gitignore 失效问题的步骤:
1.确认 .gitignore 格式正确
确保你的.gitignore 文件格式和语法正确。例如，要忽略 logs 目录，应该写为 logs/;忽略所有.txt 文件，应该写为*.txt 。
2.清除缓存(重新应用 .gitignore )
对于已经被Git跟踪的文件，即使你后来添加了它们的规则到.gitignore，这些文件仍然会被Git跟踪。你需要先从Git索引(暂存区)中移除它们(但保留在工作目录中)，然后让.gitignore生效。可以使用以下命令来实现:
git rm-r--cached .
git add .
git commit -m "Apply .gitignore"
git rm -r --cached .命令会从Git索引中移
除所有文件(-r 表示递归，--cached 表示保留工作目录文件，.表示当前目录)，但由于 .gitignore 的存在，被忽略的文件不会被重新加入到索引中。
然后通过 git add.和 git commit 重新添加
和提交剩余的文件。
3.检查全局 .gitignore
如果问题仍然存在，检查是否有全局的 .gitignore 设置影响到了你的项目。可以通过 git config --get core.excludesfile 查看是否设置了全局的 ·gitignore 文件，并确认其规则。
4.检查 .git/info/exclude
.git/info/exclude文件也可以定义忽略规则，而且这些规则只在当前仓库有效。检查这个文件以确保没有与.gitignore 冲突的规则。
在Git中，如果你想强制切换到其他分支，可以使用git checkout 命令或 git switch 命令(Git 2.23及更高版本引入)配合一些参数来实现。这种操作在你的当前分支有未提交的更改，而你不想提交或保留这些更改时非常有用。
使用 git checkout 强制切换分支
git checkout -f
-f 或 --force 选项会强制Git切换到指定的分支，放弃当前分支上所有未提交的更改。
使用 git switch 强制切换分支
对于支持 git switch 命令的Git版本，可以使用
git switch -f
-f 或 --force 选项同样用于放弃当前分支上所有未提交的更改，并强制切换到指定分支。
注意
使用强制切换分支的操作会丢失未提交的更改，包括工作目录和暂存区中的更改。因此，只有在你确信不需要这些更改，或者更改已经被另外保存的情况下才应该使用这种操作
当Git报告"unable to access"错误时，这通常指的是Git尝试访问远程仓库时遇到了问题。这个问题可能由多种原因导致，包括网络问题、SSH/HTTPS配置错误、权限问题等。以下是一些解决这个问题的通用步骤:
1.检查网络连接
确保你的计算机可以正常访问互联网。尝试访问远程仓库所在的网站(如GitHub、GitLab等)来确认网络连接。
2.检查远程仓库URL
使用 git remote-v 检查远程仓库的URL是否。正确。错误的URL是常见的问题之一。
如果URL不正确或已更改，使用 git remoteset-url origin 新的仓库URL 来更新。
3.SSH连接问题
如果使用SSH连接，确保SSH密钥已正确添加到ssh-agent中，并且相应的公钥已添加到远程仓库的账户设置中。
运行 ssh -T gitegithub.com (将 github.com替换为你的Git服务提供商的主机)来测试SSH连接。4.HTTPS连接问题
对于HTTPS连接，如果出现身份验证问题，请确保你的凭证是正确的。对于某些服务，你可能需要生成个人访问令牌(PAT)作为密码。
考虑使用凭证助手来保存用户名和密码或个人访问令牌。
5.检查权限设置
确保你的用户账户有权限访问和操作远程仓库。这可能需要检查远程仓库的权限设置或与仓库管理员联系
6.代理和防火墙
如果你在使用代理服务器或你的网络连接受到防火墙的限制，你可能需要配置Git以使用代理。这可以通过设置 http.proxy 或 https.proxy 配置项完成。
git config --global http.proxy http://代理地git config --global https.proxy https://代理1
如果不再需要代理设置，可以用 git config一-global--unset http.proxy 和 git config一-global --unset https.proxy 来移除它们。
7.清理Git凭证缓存
如果使用了Git凭证缓存，尝试清理缓存或重新输入凭证。在Windows上，可以通过Windows凭证管理器来管理Git凭证。
在Git中，如果你在执行 git pull 之后想要回滚到之前的版本，有几种方法可以实现，取决于你想要达到的具体效果。以下是一些常用的策略:
1.使用 git reset
git reset 命令可以将当前分支的HEAD指针移动到指定的历史提交。这个命令有几种模式，根据你的雷要可以选择适合的一种:
软重置(Soft Reset)
git reset --soft HEAD~1
这会撤销最近的一次 git pull 操作，将这些更改放回暂存区，但保留工作目录中的文件不变。
混合重置(Mixed Reset，默认):1 git reset HEAD~1
这会撤销最近的一次 git pull 操作，将这些更改放回工作目录，暂存区和工作目录都会被修改。
硬重置(Hard Reset)
git reset --hard HEAD~1 这会彻底撤销最近的 git pull，包括暂存区和工作目录中的更改 回到pull之前的状态。
2.使用 git revert
如果你想要保留对 git pull 的更改记录，并且希望能够在项目历史中看到撤销更改的明确操作，可以使用 git revert 。这个命令会创建一个新的提交，它是对一个或多个旧提交的逆操作。
git revert -m 1 HEAD
注意: git revert 对于撤销合并提交特别有用， -m1 选项指定撤销合并中父提交的哪一方。
3.检出到特定提交
如果你只是想查看或临时回到某个特定的提交，可以使用 git checkout 或 git switch (Git 2.23+)命令:
git checkout
或者使用 git switch (对于支持的Git版本):
git switch -c new-branch
这会让你在一个新分支上工作，不影响当前分支的状态。
如果你已经做了一次commit操作，但还没有执行git push 将更改推送到远程仓库，你可以使用几种不同的方法来撤销这次提交。选择哪种方法取决于你想要达到的具体结果:
1.使用 git reset
git reset 命令用于将当前分支的HEAD移动到指定的状态，有三种模式:[--soft--mixed (黑大认)--hard .
软重置(--soft )
git reset --soft HEAD~1
这将撤销最后一次提交，但保留更改在暂存区，允许你重新提交。
混合重置( --mixed )
git reset HEAD~1
这将撤销最后一次提交，并将更改放回工作目录你可以修改这些更改或决定不再提交，
硬重置( --hard )
git reset --hard HEAD~1
2.使用 git commit --amend
如果你只是想修改最后一次提交的信息，或者忘记将某些更改加入到最后一次提交中，你可以使用 gitcommit --amend 来修改上一次提交 I
git commit --amend -m"新的提交信息'
如果需要添加遗漏的更改，先用 git add 添加它们，然后运行上面的命令，不需要-m选项。
3.创建一个新的逆向提交(使用 git revert)
如果你不想改变项目历史，可以使用 git revert 来创建一个新的提交，这个提交会撤销之前的一个或多个提交带来的更改:
git revert HEAD
这对于需要保持项目历史不变的情况很有用，比如在公共仓库中工作。
在GitHub或GitLab上删除文件夹，实质上是删除该文件夹下的所有文件，并将这个更改提交到仓库。Git不跟踪空文件夹，所以一旦文件夹内的所有文件都被删除，文件夹自然就不存在于仓库中了。这个过程可以通过命令行(推荐)或直接在GitHub或GitLab的Web界面上进行。
使用命令行删除文件夹
1.克隆仓库(如果你还没有本地副本):
1 git clone https://github.com/用户名/仓库名.git2 cd 仓库名
2.**删除文件夹**:
使用`git rm`命令删除文件夹及其内容，并提交更改
bash
git rm -r 文件夹名称
git commit -m"删除了指定文件夹"
推送更改到远程仓库
git push origin 分支名称1
这将应用你的更改到远程仓库，删除了指定的文件夹
使用GitHub或GitLab的Web界面删除文件夹
虽然直接在Web界面上删除整个文件夹不总是直接支持，但你可以逐个删除文件夹内的文件，然后提交这些更改。
在GitHub上:
1进入你的仓库，浏览到要删除的文件夹，
2点击文件夹内的每个文件旁边的删除按钮(垃圾桶图标)。
3每次删除文件后，输入提交消息并提交更改只
4一旦文件夹内的所有文件都被删除，文件夹就会自动从仓库中移除。
在Git中，你可以通过指定分支的方式来克隆仓库这样做可以只克隆你感兴趣的分支，而不是整个仓库的所有分支。这对于大型仓库特别有用，可以节省时间和空间。以下是如何执行这个操作的步骤:
使用 git clone 命令克隆指定分支
git clone -b
告诉Git只克隆指定的分--single-branch :支
示例
如果你想克隆GitHub上某个仓库的 feature-branch分支，命令将类似于:
git clone -b feature-branch --single-branch ht
这条命令会克隆远程仓库中的 feature-branch 分丈到本地，并且只包含这个分支的内容，
在Git中还原已经 push 并公开的提交需要小心处理因为这涉及到改变公共历史。这种操作可能会对其他协作者产生影响。以下是处理这种情况的几种方法
使用 git revert
git revert 命令用于创建一个新的提交，这个新提交是对一个旧提交的逆向操作。这是处理公开提交的首选方法，因为它不改变项目的历史
git revert
这会生成一个新的提交，撤销指定提交的更改。
然后你可以安全地 push 这个更改到远程仓库
使用 git reset 和 git push --force
如果你需要彻底移除一个或多个提交，可以使用 gitreset 回退到特定的状态，然后使用带有 --force选项的 git push 来覆盖远程仓库。这种方法应该非常谨慎使用，因为它会重写公共历史，
git reset --hard
git push --force
--hard 选项会丢弃所有当前分支上
git push --force 会将这些更改强制推送到远程仓库，覆盖原有历史。
通知团队成员
如果你修改了公开的提交历史(无论是通过 revert还是 reset)，务必通知所有团队成员。他们可能需要采取额外的步骤来同步更改，如使用 git pull--rebase来更新本地仓库
在Git中，你可以使用 git show 和 git diff-tree 命令来找到特定提交中已更改的文件列表。这些命令提供了关于提交所包含更改的详细信息，包括哪些文件被添加、修改或删除。
使用 git show
git show 命令显示一个对象(如提交)的信息，包括提交信息和内容更改的差异。要仅获取更改的文件列表，可以使用--name-only或 --name-status 选项:
git show --name-only
--name-only 显示提交中更改的文件列表。
如果你想看到更改类型(例如，是否是添加(A)修改(M)还是删除(D))，可以使用:
git show --name-status
使用 git diff-tree
git diff-tree 命令也可以用来查看特定提交中的更改，尤其是更改的文件列表:
git diff-tree --no-commit-id --name-only -r
--no-commit-id 省略提交ID的输出、
--name-only 仅显示已更改的文件的名称。
-r告诉 git diff-tree 递归地显示所有子目录中的更改。
如果你同样对更改类型感兴趣，可以替换--name-only为--name-status
在Git中，将多次提交压缩成一次提交通常通过 gitrebase命令实现，特别是使用它的交互模式(-i或 --interactive)。这种做法可以让你整理提交史，合并相关的小更改，或者在推送到远程仓库前清理提交记录。以下是如何操作的步骤:
1.启动交互式变基
假设你想压缩最近的N次提交，你可以使用如下命令启动交互式变基:
git rebase -i HEAD~N
这里的 N是你想要重新审视的提交数量， HEAD~N 表示从当前提交(HEAD)向回数N个提交
2.选择要压缩的提交
执行上述命令后，文本编辑器会打开，列出了最近的N次提交，每个提交前都有 pick 字样。要压缩提交，你需要将除了第一个提交之外的所有提交前的pick 改为 squash 或简写为s。这表示你想将这些提交合并到它们上面的提交中。
3.重新定义提交信息
保存并关闭编辑器后，Git会启动另一个编辑器窗口，让你有机会重新定义新压缩后的提交信息。你可以编辑提交信息，以准确反映这次压缩提交的内容，
4.完成变基
完成提交信息的编辑并保存后，Git会完成变基过程，此时你的N次提交已经被压缩成了一次提交。
git bisect 是一个强大的Git命令，用于通过二分查找快速定位引入错误(回归)的提交。当你面对一个长期开发的项目，突然发现一个之前未发现的bug，但不确定是哪个提交引入的时， git bisect 可以帮助你高效找到问题的源头，
如何使用 git bisect
使用 git bisect 涉及以下几个步骤
1.启动二分查找
首先，启动 git bisect 会话
git bisect start
2.标记“坏”提交
接下来，你需要标记一个已知的“坏”提交，即一个包含错误的提交。如果当前HEAD就包含了这个错误你可以简单地执行:
git bisect bad
如果错误存在于特定的提交中，你可以指定那个提公.
git bisect bad
3.标记“好”提交
然后，标记一个“好”提交，即一个没有错误的早期提交:
git bisect good
这里的
4.二分查找
Git现在会自动检出一个位于“好”和“坏”提交之间的提交。你需要测试当前的代码状态，判断这个提交是好”是“坏”。然后，使用 git bisect good 或 gitbisect bad 命令来告诉Git测试的结果。Git会根据你的反馈继续二分查找，再次检出另一个提交供你测试。
这个过程会重复进行，每次测试都会让搜索范围缩小-半，直到定位到引入错误的具体提交。
5.结束二分查找
一旦找到了引入错误的提交，你可以结束 gitbisect 会话，返回到正常的工作状态:
git bisect reset
这会将你的HEAD检出回开始二分查找前的状态
要在提交之前运行代码质量检查工具，并在测试失败时阻止提交，你可以利用Git的钩子(hook)机制。Git钩子是在特定操作发生时触发的脚本，例如提交1、提交消息编辑前( prepare-前(pre-commit)commit-msg)、提交后( post-commit)等。
设置 pre-commit 钩子
pre-commit 钩子在提交进入暂存区之前运行，是阳止不符合要求的提交的理想位置。以下是如何设置pre-commit 钩子的步骤
1.创建钩子脚本
进入你的Git存储库目录
导航到 .git/hooks 子目录。你会发现许多示例钩子脚本。
创建一个名为 pre-commit 的新文件(如果已存在，则编辑它)。确保这个文件没有文件扩展名。
给 pre-commit 文件添加执行权限:
chmod +x.git/hooks/pre-commit
2.编辑 pre-commit 脚本
使用文本编辑器打开 .git/hooks/pre-commit 文件
在文件中，你可以编写或调用任何脚本来运行代码质量检查工具。这可以是shell脚本、Python脚本或任何你的项目所使用的检查工具命令。
例如，如果你使用的是JavaScript项目，可能会想在提交前运行ESLint:
#!/bin/sh
eslint "
如果 eslint 命令返回非零值(表示有错误)pre-commit 钩子会阻止提交。
确保脚本在检测到问题时返回非零值。这是告诉Git阻止提交的信号，
要检查一个分支是否已经被合并到 master分支，你可以使用Git的几个命令来进行检测。以下是几种方法:
1.使用 git branch --merged
这个命令列出了所有已经被合并到当前分支的分支要检查是否一个特定的分支已经被合并到 master首先切换到 master分支，然后使用 git branch -lmerged :
git checkout master
git branch --merged
这将列出所有已经被合并到 master 的分支。如果你的分支名出现在列表中，那么这个分支已经被合并到master 。
2.使用 git merge-base
git merge-base 命令找出两个分支最近的共同祖先。你可以使用这个命令和 git branch 命令结合来检查分支是否已经合并:
git merge-base
然后，使用 git show 来检查这个共同祖先是否是分支的最新提交:
3.使用 git log
另一种方法是使用 git log 命令来搜索分支的提交是否出现在 master 分支的历史中:
git checkout mastergit log --graph --oneline --decorate
4.使用 git cherry
git cherry 命令显示两个分支间的差异提交。未被合并的提交会被标记为 +:
git checkout master
git cherry master
如果命令没有输出(或者没有标记为+的提交)则表示分支的更改已经全部合并到 master。