当你学习 Git 时，可能会被其庞大的命令集和各种概念所吓到。但实际上，Git 并不要求死记硬背每一个命令，更重要的是理解其工作流程和使用场景。这篇文章的目的就是帮助你简化 Git 的学习过程，让你发现 Git 其实并不需要刻意去背，只需要真正理解它，就能轻松掌握。现在，就让我们一起踏上探索 Git 世界的旅程吧！
Git 是最流行的分布式版本控制系统（Distributed Version Control System，简称 DVCS）。它由 Linus Torvalds 创建，当时非常需要一个快速、高效和大规模分布式的源代码管理系统，用于管理 Linux 源代码。
由于 Linus 对几乎所有现有的源代码管理系统抱有强烈的反感，因此他决定编写自己的源代码管理系列。2005 年 4 月，Git 就诞生了。到了 2005 年 7 月，维护工作就交给了 Junio Hamano，自此他就一直在维护这个项目。
虽然最初只用于 Linux 内核，但 Git 项目迅速传播，并很快被用于管理许多其他 Linux 项目。现在，几乎所有的软件开发，尤其是在开源世界中，都是通过 Git 进行的。
版本控制是指对软件开发过程中各种程序代码、配置文件及说明文档等文件变更的管理，是软件配置管理的核心思想之一。版本控制技术是团队协作开发的桥梁，助力于多人协作同步进行大型项目开发。软件版本控制系统的核心任务就是查阅项目历史操作记录、实现协同开发。
常见版本控制主要有两种：集中式版本控制和分布式版本控制。
集中式版本控制系统，版本库是集中存放在中央服务器的。工作时，每个人都要先从中央服务器获取最新的版本。完成之后，再把自己添加/修改的内容提交到中央服务器。所有文件和历史数据都存储在中央服务器上。SVN 是最流行的集中式版本控制系统之一。
集中式版本控制系统的缺点就是必须联网才能使用，如果使用局域网还好，速度会比较快。而如果是使用互联网，网速慢的话，就可能需要等待很长时间。除此之外，如果中央服务器出现故障，那么版本控制将不可用。如果中心数据库损坏，若数据未备份，数据就会丢失。
分布式版本控制系统，每台终端都可以保存版本库，版本库可以不同，可以对每个版本库进行修改，修改完成后可以集中进行更新。虽然它没有中心服务器，但可以有一个备份服务器，它的功能有点类似于 SVN 的中央服务器，但它的作用仅是方便交换修改，而不像 SVN 那样还要负责源代码的管理。Git 是最流行的分布式版本控制系统之一。
和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑损坏不会影响到协作的其他人。
Git 相较于 SVN：
在Git官网下载、安装即可：https://git-scm.com/download。
安装完成之后，可以使用以下命令来查看 Git 是否安装成功：
git --version如果安装成功，终端会打印安装的 Git 的版本：
要给项目初始化一个Git仓库，可以在终端中打开项目目录，执行以下命令即可：
git init初始化之后，就会创建一个名为.git的新子文件夹，其中包含 Git 将用于跟踪项目更改的多个文件和更多子目录：
在使用 Git 进行代码管理时，不希望一些文件出现在跟踪列表中，比如node_modules文件。这种情况下，可以在项目的根目录中创建一个名为.gitignore的文件，在该文件中列出要忽略的文件和文件夹，来看一个示例：
# 所有以.md结尾的文件*.md # lib.a不能被忽略!lib.a# node_modules和.vscode文件被忽略node_modules.vscode# build目录下的文件被忽略build/# doc目录下的.txt文件被忽略doc/*.txt# doc目录下多层目录的所有以.pdf结尾的文件被忽略doc/**/*.pdf注意：以 # 符号开头的行是注释。
我们可以在本地克隆Git存储库上的代码，首先要找到Git存储库上的HTTPS或SSH的地址，如下：
图片
然后使用以下命令将远程仓库克隆到本地：
git clone https://github.com/facebook/react.git从Git的角度来看，可以在三个区域进行文件更改：工作区，暂存区和存储库。
Git 工作目录下的文件存在两种状态：
其中已跟踪状态可以细分为以下三种状态：
可以通过运行以下命令来检查当前分支的状态：
git status显示结果如下：
此命令不会更改或更新任何内容。它会打印出哪些文件被修改、暂存或未跟踪。未跟踪的文件是尚未添加到 git 索引的文件，而自上次提交以来已更改的文件将被视为已被 git 修改。
当安装Git后首先要做的就是配置所有本地存储库中使用的用户信息。每次Git提交都会使用该用户信息。
config 命令适用于不同的级别：
下面的配置均为写入系统级别：
可以使用以下命令设置使用 Git 时的用户名：
git config --global user.name "name"可以使用以下命令查看设置的user.name：
git config user.name可以使用以下命令设置使用 Git 时的邮箱：
git config --global user.email "email"可以使用以下命令查看设置的 email：
git config user.email除了上述两个基本的设置之外，还可以设置命令的颜色，以使输出具有更高的可读性：
git config --global color.ui auto通过上面的命令设置的信息会保存在本地的.gitconfig文件中。可以使用以下命令查看所有配置信息：
git config --list如果在全局输入这个命令，就会显示全局的配置：
如果在使用 Git 的项目中输入该命令，除了会显示全局的配置之外，还会显式本地仓库的一些配置信息，如下：
git config 命令为我们提供了一种创建别名的方法，这种别名通常用于缩短现有的命令或者创建自定义命令。来看一个例子：
git config --global alias.cm "commit -m"这里为commit -m创建一个别名 cm，这样在提交暂存区文件时，只需要输入以下命令即可：
git cm <message>分支是源代码控制的核心概念，它允许将工作分离到不同的分支中，这样就可以自由地处理源代码，而不会影响其他任何人的工作或主分支中的代码。下面来看一些常见的分支操作。
可以使用以下命令来查看当然所在的分支以及该项目所有的分支情况：
git branch该命令可以列出项目所有的本地分支，显示绿色的分支就是当前分支：
可以使用以下命令来列出所有的远程分支：
git branch -r
可以使用以下命令来查看所有的本地分支和远程分支：
git branch -a
我们在计算机上只能访问本地分支，在将分支推送到远程仓库之前，需要先创建一个本地分支。
可以使用以下命令来创建分支：
git checkout <branch>加上-b就可以在创建新的分支之后，直接切换到新创建的分支上：
git checkout -b <branch>如果想将新建的本地分支推送到远程仓库，以在远程仓库添加这个分支。可以执行以下命令：
git push -u origin <branch>可以使用以下命令来删除本地分支：
git branch -d <branch>需要注意，在删除分支之前，要先切换到其他分支，否则就会报错：
切换到其他分支再删除即可：
有时 Git 会拒绝删除本地分支，因为要删的分支可能有未提交的代码。这是为了保护代码以避免意外丢失数据。可以使用以下命令来强制删除本地分支：
git branch -D <branch>这样就删除成功了：
当然，我们也可以删除远程仓库分支，执行以下命令即可：
git push origin --delete <name>可以使用以下命令来将分支重命名：
git branch -m <oldname> <newname>如果newname名字分支已经存在，则需要使用-M来强制重命名：
git branch -M <oldname> <newname>可以使用以下命令将其他分支的代码合并到当前分支：
git merge <branch>如果想将A分支合并到B分支，就要先切换到B分支，然后执行命令：git merge A。
git rebase 用于将一个分支的提交记录合并到另一个分支上。
原理： 通过找到两个分支的最近共同祖先，然后提取当前分支相对于该祖先的历次提交，保存为临时文件。接着，将当前分支指向目标分支的最新提交，最后依序应用之前保存的修改。这样，就可以将一个分支上的修改“移动”到另一个分支上，实现代码的整合。
使用git rebase的步骤如下：
假设有一个名为feature的分支，它包含了一些新功能的开发代码。同时，还有一个名为master的主分支，用于发布稳定版本的代码。现在，想要将feature分支上的代码合并到master分支上。首先，切换到master分支，并拉取最新的代码：
git checkout master git pull origin master然后，执行rebase命令，将feature分支的提交记录合并到master分支上：
git rebase featureGit会开始分析两个分支的提交记录，并尝试自动合并它们。如果出现冲突，需要手动解决冲突，并使用git add命令标记已解决的文件。例如，假设在合并过程中出现了一个名为conflict.txt的文件冲突，你可以使用文本编辑器打开该文件，解决冲突，然后执行以下命令：
git add conflict.txt git rebase --continue一旦所有冲突都解决并且所有提交记录都成功合并，可以使用git push命令将更改推送到远程仓库：
git push origin master这样就成功地将feature分支上的代码合并到了master分支上，并保持了提交历史的清晰和整洁。
git rebase和git merge都是用于将不同分支的代码整合到一起的Git命令，但它们在实现方式、结果和适用场景上有一些区别。
Git 数据工作流程如下：
可以使用以下命令来暂存已修改的文件，命令最后需要指定要暂存的文件名称：
git add <filename>如果想要将所有未跟踪和修改的文件添加到暂存区，可以执行以下命令：
git add .此时分支的状态如下：
可以使用以下命令将暂存区的文件修改提交到本地仓库，
git commit -m "meaasge"其中-m参数表示message日志信息，参数后面要加一个日志信息，用双引号括起来。
此时分支的状态如下：
如果上次提交暂存的messge写错了怎么办呢？可以使用使用以下命令来更新提交，而不需要撤销并重新提交：
git commit --amend -m <message>如果有一个新的文件修改，也想提交到上一个commit中，可以使用以下命令来保持相同的提交信息：
git add .git commit --amend --no-edit假如我们正在开发迭代功能，但是还没开发完。这时有一个紧急的bug需要修复上线。可能就需要切换到一个hotfix分支去修复bug。这时对于开发了一部分的功能创建提交是没有逻辑意义的。可以使用以下任一命令来存储修改的内容：
git stashgit stash pushgit stash push -m "<stash message>"该命令回保存所有未提交的更改并恢复到上次提交时存储库的状态。
当想再次继续开发此功能时，就可以使用以下命令检查所有存储：
git stash list这时终端中就会显示带有时间戳的所有已经暂存的列表。可以使用以下任一命令来取回所有的更改：
git stash applygit stash popapply 和 pop 之间的区别在于，pop 应用了 stash 中的更改并将其也从 stash 中删除，但 apply 即使在应用后仍将更改保留在 stash 中。
可以使用以下任一命令应用存储列表中的第 N 个存储：
git stash apply stash@{N}git stash apply <n>整个过程的输出如下：
在不同分支之间进行代码合并时，通常会有两种情况：一种情况是需要另一个分支的所有代码变动，那么就可以直接合并（git merge），另一种情况是只需要部分代码的变动（某几次提交），这时就可以使用以下命令来合并指定的提交：
git cherry-pick <commit hash>建议添加 -x 标志，因为它会生成标准化的提交消息，通知用户它是从哪里pick出来的：
git cherry-pick -x <commit hash>那么这个commit hash是从哪里来的呢？可以在需要被合并的分支上执行以下命令：
git log这时终端就会显示出所有的提交信息：
这里黄色文字中commit后面的部分就是commit hash，复制即可。
Git允许我们在本地检查特定的提交。输入以下命令就可以查看有关当前提交的详细信息：
git show输出的结构如下，可以看到，它显示出了上次提交的commit id、作者信息（邮箱和姓名）、提交日期、commit message、代码diff等：
还可以使用HEAD~n语法或提交哈希来检查过去的提交。使用以下命令就可以获取往前数的第三次提交的详细信息：
git show HEAD~3除此之外，还可以添加一个--oneline标志，以简化输出信息：
git show --oneline这样提交信息就简洁了很多：
可以使用以下命令来返回每个贡献者的commit次数以及每次commit的commit message：
$ git shortlog其可以添加两个参数：
加上这两个参数之后就可以看到每个用户中的提交次数以及排名情况：
git shortlog -sn这样就会显示出该项目所有贡献者的commit次数，从上到下依次减小：
除此之外，还可以添加一个--no-merges标志，以忽略合并提交的次数：
git shortlog -sn --no-mergesgit rev-list 用于列出仓库中的提交（commit）记录。它按照时间倒序显示提交记录，并可以根据不同的选项和参数进行筛选和排序。
下面是git rev-list的一些基本用法：
列出所有提交记录：
git rev-list这将显示仓库中所有的提交记录，按照时间倒序排列。每个提交记录都有一个唯一的SHA-1哈希值作为标识。
列出某个分支的提交记录：
git rev-list <branch-name>将<branch-name>替换为你要查看的分支的名称。这将显示该分支上的所有提交记录。
列出某个提交之后的提交记录：
git rev-list <commit-id>..将<commit-id>替换为你要查看的提交的SHA-1哈希值。这将显示该提交之后的所有提交记录。
列出两个提交之间的提交记录：
git rev-list <commit-id1>..<commit-id2>将<commit-id1>和<commit-id2>替换为你要查看的两个提交的SHA-1哈希值。这将显示从<commit-id1>到<commit-id2>之间的所有提交记录。
列出某个文件的所有提交记录：
bash复制代码git rev-list -- <file-path>将<file-path>替换为你要查看的文件的路径。这将显示涉及该文件的所有提交记录。
git notes允许用户为Git对象（如提交、树、标签等）添加注释或备注信息。这些注释信息是以键值对的形式存储的，其中键是一个唯一的引用，而值则是与该引用关联的注释内容。
要使用git notes，可以按照以下步骤进行操作：
添加注释：使用git notes add -m "Your note message" <object>命令向一个对象添加注释。例如，要向提交abc123添加注释，可以执行git notes add -m "This is a note for commit abc123" abc123。
git blame 用于追溯文件历史修改记录,它可以显示指定文件中每一行代码的最后修改者以及修改时间，帮助开发者了解代码的演变过程。
以按照以下步骤使用git blame命令：
git blame命令将列出文件的每一行，并显示最后一次修改该行的提交信息，包括提交的哈希值、作者、修改时间和提交注释等。这样，你可以轻松地找到代码中引入bug的提交，或者识别特定代码段的贡献者。
除了基本的用法，git blame命令还接受一些参数来调整输出。例如，使用-L <start>,<end>参数可以指定查看的行范围，只显示指定行范围内的代码修改信息。使用-p参数可以显示每一行的详细信息，包括提交的哈希值、作者、时间戳和行号。此外，还可以使用-C和-M选项来查找代码重命名和移动的情况，以便更好地追踪代码的变化。
git archive 用于创建存档（archive）文件，通常是一个压缩文件，包含了Git仓库中的特定文件或目录。这个命令允许你将Git仓库中的文件打包成一个独立的文件，方便备份、传输或发布。
要使用git archive命令，需要指定存档文件的格式（如.zip、.tar等），以及要包含的文件或目录。以下是一些常用的git archive命令的用法：
git archive --format=tar --prefix=my-project/ HEAD | gzip > my-project.tar.gz这个命令将创建一个名为my-project.tar.gz的压缩文件，其中包含了当前分支（HEAD）的最新代码。--prefix选项用于在存档文件中添加一个前缀目录my-project/。
git archive --format=zip --output=my-files.zip path/to/file1 path/to/file2这个命令将创建一个名为my-files.zip的压缩文件，其中只包含了指定的文件或目录。你可以通过路径来指定要包含的文件或目录。
注意，git archive命令只会包含文件的当前版本，而不会包含Git的元数据（如提交历史、分支信息等）。因此，存档文件主要用于备份或发布代码，而不是作为完整的Git仓库来使用。
git verify-commit用于验证提交（commit）的GPG签名。GPG（GNU Privacy Guard）是一种加密软件，可以用于为Git提交添加数字签名，以确保提交的完整性和真实性。
要使用git verify-commit命令，需要先确保已经为Git配置了GPG签名，并且至少有一个提交是带有GPG签名的。然后按照以下步骤进行操作：
git verify-commit命令将检查指定提交的GPG签名，并输出验证结果。如果签名有效且未被篡改，命令将显示“Good signature”或类似的消息。如果签名无效或存在问题，命令将显示相应的错误消息。
除了基本的用法，git verify-commit命令还接受一些参数来调整输出和行为。例如，使用--raw参数可以打印原始的GPG状态输出，而不是人类可读的输出。使用--verbose参数可以打印提交对象的详细内容，以便更详细地了解验证过程。
注意，要使用git verify-commit命令，必须已经为Git配置了GPG签名，并且至少有一个提交是带有GPG签名的。如果提交没有签名或签名无效，该命令将无法验证提交的真实性。
可以使用以下命令来查看远程仓库：
git remote该命令会列出指定的每一个远程服务器的简写。如果已经克隆了远程仓库，那么至少应该能看到 origin ，这是 Git 克隆的仓库服务器的默认名字：
可以执行以下命令来获取远程仓库的地址：
git remote -v其中fetch是获取，push是推送：
可以使用以下命令来查看更加详细的信息：
git remote show origin输出结果如下：
可以使用以下命令来将本地项目链接到远程仓库：
git remote add <remote_name> <remote_url>其中：
该命令允许 Git 跟踪远程存储库并将本地存储库连接到远程仓库。
可以使用命令来移除远程仓库：
git remote rm origin需要注意，该命令只是从本地移除远程仓库的记录（也就是解除本地仓库和远程仓库的关系），并不会真正影响到远程仓库。
可以使用以下命令来从远程仓库获取最新版本到本地仓库，不会自动merge（合并数据）：
git fetch由于该命令不会自定合并数据，所以该命令执行完后需要手动执行 git merge 远程分支到所在的分支。
可以使用以下命令来将远程指定分支拉取到本地指定分支上：
git pull origin <远程分支名>:<本地分支名>使用以下命令来将远程指定分支拉取到本地当前分支上：
git pull origin <远程分支名>使用以下命令开将与本地当前分支同名的远程分支拉取到本地当前分支上：
git pull注意：如果当前本地仓库不是从远程仓库克隆，而是本地创建的仓库，并且仓库中存在文件，此时再从远程仓库拉取文件的时候会报错（fatal: refusing to merge unrelated histories ），解决此问题可以在git pull命令后加入参数--allow-unrelated-histories，即：
git pull --allow-unrelated-histories可以使用以下命令将本地指定分支推送到远程指定分支上：
git push origin <本地分支名>:<远程分支名>可以使用以下命令将本地指定分支推送到与本地当前分支同名的远程分支上：
git push origin <本地分支名>使用以下命令将本地当前分支推送到与本地当前分支同名的远程分支上：
git push可以使用以下命令来将本地分支与远程同名分支相关联：
git push -u origin <本地分支名>由于远程库是空的，第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令为git push。
如果只是简单地从工作目录中手工删除文件，运行 git status 时就会在 Changes not staged for commit 的提示
可以使用以下命令将文件从暂存区和工作区中删除：
git rm <filename>如果删除之前修改过并且已经放到暂存区域的话，则必须要用强制删除选项 -f：
git rm -f <filename>如果想把文件从暂存区域移除，但仍然希望保留在当前工作目录中，换句话说，仅是从跟踪清单中删除，使用 --cached 选项即可：
git rm --cached <filename>可以使用以下命令进行递归删除，即如果后面跟的是一个目录做为参数，则会递归删除整个目录中的所有子目录和文件：
git rm –r *进入某个目录中，执行此语句，就会删除该目录下的所有文件和子目录。
取消修改有三种情况：
未使用 git add 将修改文件添加到暂存区这种情况下，可以使用以下命令来撤销所有还没有加入到缓存区的修改：
git checkout -- <filename>需要注意，此文件不会删除新建的文件，因为新建的文件还没加入到Git管理系统重，所以对Git来说事未知的，需要手动删除。
已使用 git add 将修改文件添加到暂存区，未使用 git commit 提交缓存这种情况下，相当于撤销了 git add 命令对于文件修改的缓存：
git reset HEAD <filename>上面的命令可以撤销指定文件的缓存，要想放弃所有文件的缓存，可以执行以下命令：
git reset HEAD需要注意，在使用此命令后，本地的修改并不会消失，而会回到第一种情况。要想撤销本地的修改，执行第一种情况中的命令即可。
除此之外，还可以指定返回到N次提交之前的阶段，执行以下命令即可：
git reset HEAD~N这样就能退回到n个版本之前，同样不会修改本地文件的内容，这些新的内容会变成未更新到缓存区的状态。
已使用 git commit 提交缓存这种情况下，可以使用以下命令来回退到上一次 commit 的状态：
git reset --hard HEAD^也可以使用以下命令来回退到任意版本：
git reset --hard <commit_id>注意，使用 git log 命令来查看 git 提交历史和 commit id。
这是一个很重要的命令，假如回退到某个旧版本，现在想恢复到新版本，又找不到新版本的commit id怎么办？Git 提供了下面的命令用来记录每一次命令：
git reflog show HEADgit reflog执行之后输出如下：
可以看到，最左侧黄色字体就是修改的 commit id，根据这个id就可以将代码恢复到对应节点位置。HEAD@{n}表示HEAD更改历史记录，最近的操作在上面。
假如需要把代码回退到HEAD@{5}处，可以执行以下命令：
git reset --hard HEAD@{5}或者执行下面的命令：
git reset --hard 8a0fd74需要注意，如果有任何本地修改，该命令也会将其销毁，因此在reset之前建议使用stash将本地修改储存。
git clean 用于从工作目录中删除未跟踪的文件。这些文件通常是那些由编辑器、构建过程或其他工具生成的临时文件或副产品，而不是Git仓库中的一部分。使用git clean命令可以帮助保持工作目录的整洁，避免这些未跟踪的文件干扰正常的Git操作或导致意外的提交。
git clean命令的基本语法如下：
git clean [-dfnxq] [-e <pattern>] [-i] [-n] [-f] [-r | -R] [<path>...]下面是一些常用的选项和参数：
以下是一些使用git clean命令的示例：
删除所有未跟踪的文件和目录：
git clean -df仅显示将要删除的文件和目录列表：
git clean -n强制执行删除操作，不提示用户确认：
git clean -f删除所有未跟踪的文件和目录，包括被.gitignore文件忽略的内容：
git clean -dfx注意，使用git clean命令时要小心，确保不会误删除重要的文件。在执行删除操作之前，最好先使用-n选项来预览要删除的内容。
git rm 和 git clean 都是删除文件，那他们之间有什么区别呢？
标签指的是某个分支某个特定时间点的状态，通过标签可以很方便的了解到标记时的状态。
标签有两种类型 ：
可以使用以下命令来获取所有标签：
git tag它会列出所有标签的名称：
可以使用以下命令来查看某一个标签的详细信息：
git show <tag_name>
还可以根据条件来显示标签，比如列出以v1.开头的所有tag：
git tag -l "v1."可以使用以下命令在本地创建新标签：
git tag <tag_name>例如：
git tag v1.0.0通常遵循的命名模式如下：
v<major>.<minor>.<patch>除此之外，我们还可以为特定的commit创建标签，其命令格式如下：
git tag <tagname> <commit_sha>以上面的的形式创建的标签都属于轻量标签，下面来看看如何创建一个附注标签。
在创建标签时，可以添加一个-a标志以创建一个带备注的标签，备注信息使用-m message来指定：
git tag -a <tagname> -m "<message>"标签创建完成之后就可以使用以下命令将其推送到远程仓库：
git push origin --tags以上命令会将本地所有tag都推送到远程仓库。如果想推送指定标签，可以执行以下命令：
git push origin <tagname>可以使用以下命令来切换标签：
git checkout <tagname>可以使用以下命令来删除本地仓库指定标签：
git tag -d <tagname>可以使用以下命令来删除远程仓库指定标签：
git push origin :refs/tags/<tagname>也可以使用以下命令来删除远程仓库的指定标签：
git push origin --delete <tagname>可以使用以下命令来将远程仓库的标签拉取（同步）到当前分支：
git fetch --tags检出标签实际上就是在标签的基础上进行其他开发或操作。需要以标签指定的版本为基础版本，新建一个分支，继续其他的操作。执行以下命令即可：
git checkout -b <branch> <tagname>git verify-tag 用于验证标签（tag）的 GPG 签名。GPG（GNU Privacy Guard）是一种用于文件签名的工具，它可以确保标签的完整性和真实性，防止标签被篡改或伪造。
要使用 git verify-tag 命令，需要先确保已经为 Git 配置了 GPG 签名。然后，可以按照以下步骤进行操作：
git verify-tag 命令将检查指定标签的 GPG 签名，并输出验证结果。如果签名有效且未被篡改，命令将显示 "Good signature" 或类似的消息。如果签名无效或存在问题，命令将显示相应的错误消息。
除了基本的用法，git verify-tag 命令还接受一些参数来调整输出和行为。例如，使用 --raw 参数可以打印原始的 GPG 状态输出，而不是人类可读的输出。使用 --verbose 参数可以打印标签对象的详细内容，以便更详细地了解验证过程。
可以使用以下命令来查看分支的历史提交信息：
git log这是其最基础的用法，输出如下：
可以看到，终端上输出了该分支近期的提交记录，它包含了所有贡献者的提交。
如果想只看某个人的提交，可以添加过滤条件：
git log --author="username"当然也可以搜索多个作者的提交信息，只需要在用|分隔用户名即可，注意需要使用/来对|进行转义：
git log --author="username1/|usernmae2"这里列出的是每次提交的详细信息，如果指向看到每个提交的概要，可以在命令中添加--oneline标志：
git log --author="username" --oneline除了可以按照作者来查看日志之外，还可以按照时间查看日志。可以查看某个时间之前的日志，也可以查看某个日期之后的日志：
//某个日期之后git log --since=<date>git log --after=<date>//某个日期之前git log --until=<date>git log --before=<date>如果想查看某个具体时间区间之间的日志，可以组合以上参数：
git log --since="2022.05.15" --until="2022.05.20"如果我们想查看某个文件都在哪些提交中修改了内容，也是可以的。使用以下命令即可：
git log -- <path>比如查看README.md文件的修改记录：
在历史提交中可能会有很多次合并的提交记录，想要只查看代码合并的记录，可以执行以下命令：
git log --merges如果想查看非合并操作的操作记录，可以执行以下命令：
git log --no-merges可以按照分支查看日志，如果想查看test分支比master分支多提交了哪些内容，就可以执行以下命令：
git log master..test相反，如果想看master分支比test分支多提交了哪些内容，就可以执行以下命令：
git log test..mastergit log命令可以用来查看提交历史，此命令的问题在于，随着项目复杂性的增加，输出变得越来越难阅读。可以使用以下命令来美化日志的输出：
git log --graph --oneline --decorate输出结果如下，这样就能看到更简洁的细分以及不同分支如何连接在一起：
上面我们提到了，可以使用--oneline标志来简化日志的输出：
git log --oneline可以使用--stat标志来简要显示文件增改行数统计，每个提交都列出了修改过的文件，以及其中添加和移除的行数，并在最后列出所有增减行数小计：
git log --stat可以添加-N标志来仅显示最近N次的提交，其中N是一个正整数，例如查看最近三次提交：
git log -3可以使用-p标志来展开显示每次提交的内容差异对比：
git log -p注意，以上这些命令标识符都可以组合使用。
git diff 命令可以用来比较文件的不同，即比较文件在暂存区和工作区的差异。
当工作区有改动，暂存区为空时， diff对比的是工作区与最后一次commit提交的共同文件；当工作区有改动，暂存区不为空时，diff对比的是工作区与暂存区的共同文件。
当已缓存改动时，可以使用以下任一命令来显示暂存区（已add但未commit文件）和最后一次commit(HEAD)之间的所有不相同文件的差异对比：
git diff --cachedgit diff --staged可以使用以下命令来显示工作目录(已修改但未add文件)和暂存区(已add但未commit文件)与最后一次commit之间的的所有不相同文件的差异对比：
git diff HEAD可以使用以下命令来比较两个分支上最后 commit 的内容的差别：
git diff <分支名1> <分支名2>这样就可以显示出两个分支的详细差异，如果只是想看有哪些文件存在差异，可以在命令中添加--stat标志，这样就不会显示每个文件的内容的详细对比：
git diff <分支名1> <分支名2> --statgit bisect 采用二分查找算法来帮助开发者快速定位引入问题的提交。当在代码库中遇到错误，但不确定何时引入时，git bisect可以显著提高查找错误的效率。
原理：git bisect使用二分查找算法来缩小引入问题的提交范围。它首先将提交历史分为两半，然后询问开发者哪一半包含引入错误的提交。基于开发者的反馈，git bisect会继续将范围缩小到更小的一半，直到找到引入问题的确切提交。
使用git bisect的基本步骤如下：
假设发现了一个错误。不确定这个错误是在何时引入的，但是知道在某个特定版本的代码中该错误是不存在的。
GitLens 是一个VS Code插件，可以用来查看项目的提交记录、文件修改记录、显示每行代码的提交记录等。通过丰富的可视化和强大的比较命令获得有价值的见解。
Git History 是一个VS Code插件，增强了Git 的功能，它可以用来查看日志信息，查看和搜索历史，进行分支对比、提交对比，跨提交对比文件等。
Git Automator 是一个VS Code插件，主要用来自动化Git提交消息和 Git 工作流程。它允许用一个快捷方式添加和提交文件。它还为提交信息提供了自动填充功能。当动作很明显时，例如你删除了一个文件，Git Automator 会猜测该动作并将其添加到预填充的提交消息中。
LearnGitBranching 是一个 git 存储库可视化工具、沙箱和一系列教程和挑战。它的主要目的是帮助开发人员通过可视化的力量来理解 git。这是通过不同级别的游戏来熟悉不同的git命令来实现的。
Github：https://github.com/pcottle/learnGitBranching。
本文链接：http://www.28at.com/showinfo-26-75313-0.htmlGit 不用背，这篇文章帮助你简化 Git 的学习过程
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： 浅谈链路聚合，你学会了吗？
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
