厦门u 网站建设,最新源码,官方发布小程序开发小程序,现在用什么做网站Git教程 提交详解 1️⃣ 访问权限与时间戳2️⃣ add命令与 commit 命令3️⃣ 提交散列值4️⃣ 提交历史5️⃣ 一种特别的提交查看方法6️⃣ 同一项目的多部不同历史6.1 部分输出#xff1a;-n6.2 格式化输出#xff1a;--format、--oneline6.3 统计修改信息#xff1a;--st… Git教程 · 提交详解 1️⃣ 访问权限与时间戳2️⃣ add命令与 commit 命令3️⃣ 提交散列值4️⃣ 提交历史5️⃣ 一种特别的提交查看方法6️⃣ 同一项目的多部不同历史6.1 部分输出-n6.2 格式化输出--format、--oneline6.3 统计修改信息--stat、 --shortstat6.4 日志选项--graph 7️⃣ 多次提交7.1 status 命令7.2 存储在暂存区中的快照7.3 怎样的修改不该被提交7.4 用.gitignore 忽略非版本控制文件7.5 储藏 总结 在Git 中提交无疑是最重要的概念了。Git 管理的是软件版本而版本库中的版本是以 提交 的形式保存的。某一次的提交的覆盖范围通常是整个项目即通过一次提交该项目中的每个文件就都被存进了版本库中。 下面我们可以通过 git log --stat -1 命令来看一下提交中究竟包含了哪些重要信息其摘要如下所示。
commit 7a90822f510d4a3309dfbebda2fc9cf350ee013d (HEAD - main, origin/main-xiaoshan)
Merge: 63f2bd3 dab5fc3
Author: xiaoshanxiaoshan
Date: Fri Feb 23 13:53:47 2024 0800Merge branch main of ...
如上所示这段信息的第一行显示的是该提交的散列值 7a90822f…e013d, 紧随其后的是与作者相关的信息、该提交被创建的时间以及相应的注释信息。最后部分所说明的是哪些文件自上一版本以来发生了变化。针对每次提交Git 都会为其 计算一个由40个字符组成的唯一编码我们称之为 提交散列值 (commit hash)。 只要知道这个散列值我们就可以将项目中的文件从版本库中恢复到该提交被创建的那个时间点上。在Git 中恢复到某一版本通常被称之为 检出(checkout) 操作。 1️⃣ 访问权限与时间戳
Git 会保存每个文件原有的访问权限(即 POSIX 文件权限包含读、写、执行3种权限), 但不会保留文件的修改时间。因此在执行检出操作时文件的修改时间会被设置为当前时间。
为什么不保存修改时间呢? 这主要是因为如今的许多构建工具的重新生成项目动作都是靠这些文件的修改时间来触发的即如果最后一次修改晚于我们最后一次构建的结果我 们就进行一次新的建构过程。由于 Git 在进行检出操作时总是用当前时间来充当文件的修改时间所以就能确保这些工具正确、顺畅地完成整个构建过程。 2️⃣ add命令与 commit 命令
通常提交中会包含当前所有的修改既有新增的文件也有被删除的文件。唯一例外的是在.gitignore 文件中列出的那些文件(后面详细讨论.gitignore) 。
我们可以分 add 命令和 commit 命令这两步来创建一次提交。
注册修改 我们可以用add 命令来进行注册将所做的修改纳入下次提交。在这里你可以使用 -all 参数这表示我们会将所有修改都纳入在内。 git add --all 创建提交 现在可以创建一次新的提交了。 git commit 3️⃣ 提交散列值
乍看之下40个字符的提交散列值的确有点长。毕竟其他版本控制系统使用的都是简单的序列数(例如 Subversion) 或像1:17这样的版本名词(例如CVS)。 但是 Git的开发者选择了散列值这种形式也是有其充分理由的。 这样的提交散列值可以在本地生成。我们无需与其他计算机或中央服务器进行通信 就可以随时随地创建新的提交。而且由于提交散列值是根据文件内容及其元数据(即 作者、提交时间)计算出来的因此两次不同的修改会得到相同提交散列值的概率是非常低的。毕竟这里要面对的是2160种不同的值呢。 更为重要的是提交散列值中的信息要比单纯一个软件版本的名称要多得多。这 也是该软件版本的汇总信息。正因为如此我们才能通过 Git的 fsck 命令来查看版本库的完整性。如果其内容与相应的散列值不匹配我们就得到如下错误报告。 git fsck
error: shal mismatch 2b6c746e5e20a64032bac627f2729f72a9cba4ee
error: 2b6c746e5e20a64032bac627f2729f72a9cba4ee:
object corrupt or missing当然我们也可以在指定某个提交散列值时采用缩写形式。大致上只要指定几个足以识别该提交的字符就可以了。但如果指定的字符太少 Git 还是会报错的。
git checkout 9acc5d5efecld2d62f7e98bcc3880cda762cb831
git checkout 9acc另外我们也可以为某个提交起一个有意义的名称(例如 release-1.2.3)。这就是所谓的标记。
git checkout release-1.2.34️⃣ 提交历史
版本库中所包含的并不仅仅是一个个独立的提交它同时也存储了这些提交之间的关系。 每当我们修改了软件并确认提交时 Git 就会记下这个提交之前的版本。这些提交会形成一个关系图该图反映了整个项目的开发过程。 有趣的是每当有多个开发者同时在开发一款软件时其中的分支在创建时会如提交关系图中的C 处这般开始随后又会如G 处那样被合并。 5️⃣ 一种特别的提交查看方法
我们可以将一次提交看成一个已被冻结的版本层次但也可以将其视为自上一次提交以 来项目中所纳入的一组修改。当然我们也可以将它说成是一种差异集或一组修改。所以版本库实质上也是一部项目的修改历史。
通过 diff 命令我们可以比较出两次提交之间的差异。
a. 两次提交 两次提交之间可以有一份完整的差异清单。我们在不用提交散列值的情况下靠指定相关特定的符号名称(例如分支、标签、HEAD 等)也能获取到它。
git diff 77d231f HEADb. 与上一次提交进行比较 通过在 diff 命令中使用 ^!, 我们可以比较当前提交与上一次提交之间的差异。
git diff 77d231f^!C. 限制文件范围 我们还可以限制只显示哪些文件或目录之间的差异。
git diff 77d231f 05bcfd1 -book/bisection/d. 统计修改情况 或者我们可以通过 --stat 选项来显示每个文件中的修改数量。
git diff --stat 77d231f 05bcfd16️⃣ 同一项目的多部不同历史
首先我们需要适应 Git 的分布式架构。在(像 CVS 、Subversion 这样的)集中式版本控制系统中通常会存在一个用于存储项目历史的中央服务器。但在 Git 中每个开发者都有一个(有时是多个)属于自己的版本库克隆体。当开发者创建提交时通常是在本地完成 这一动作的。而自此之后他的版本库就有了一部不同于其他开发者版本库的历史尽管这些人所克隆的是同一个项目。
这样一来每个版本库都有一个属于它自己的故事。这些版本库之间可以通过 fetch 、pull以及 push 命令来共享彼此的提交。除此之外你也可以用 merge 命令将这些不同的历史重新合并在一起。
在许多项目中我们通常会有一个用于存储官方历史的版本库(它通常位于项目服务器上), 我们称该版本库为项目版本库 (blessed repository)。但这仅仅是一个习惯做法而已单纯从技术角度来看的话该项目的所有克隆体都是平等的。例如如果主版本库被破坏了它的另一个克隆体同样可以胜任它的工作。
当然 一个规模非常大的项目可以会被分布在多个版本库中。在这种情况下我们通常会有一个主版本库该版本库中会依次存储其各个子项目的版本库这些版本库通常称为子模块 (submodule)。
我们可以用 log 命令来显示提交历史。 a. 简单的日志输出 git log
commit 7a90822f510d4a3309dfbebda2fc9cf350ee013d (HEAD - main, origin/main-xiaoshan)
Merge: 63f2bd3 dab5fc3
Author: xiaoshanxiaoshan
Date: Fri Feb 23 13:53:47 2024 0800
...
b. 一些实用选项 git log -n 3 #Only the last three commitsgit log --oneline #Only one line per commitgit log --stat #Only show statisticslog 命令通常并不一定要显示出版本库中所有的提交。我们往往只需要它显示出当前提交的前几次提交即可。
在使用 log 命令时我们可以通过一些选项来控制自己所需要显示的提交以及它们显示 的格式。下面我们来看几个常用的选项。
6.1 部分输出-n
该选项通常用于限制输出。例如下面这个命令只显示该项目的最后3次提交 git log -n 36.2 格式化输出–format、–oneline
对于日志的输出格式我们可以用–format 选项来控制。例如 --formatfuller 选项可 以用来显示许多细节信息。而下面则是–oneline 选项所显示的概述信息。 git log --oneline
2753f19 TODO indented for illustration.
e0ffbdb Note.
4200ba2 Section on different histories of the same project.6.3 统计修改信息–stat、 --shortstat
统计类选项也是很有用的 --stat 可用来显示被修改的那些文件。 --dirstat 则可以用来 显示那些包含被修改文件的目录。而 --shortstat 则用来显示项目中有多少文件被修改以及新增或删除了多少文件。 git log --shortstat --oneline
0a6f423df (HEAD - master, origin/master-l) ...
50498817d (origin/master, origin/HEAD) ...26 files changed, 26 insertions(), 26 deletions(-)
7cb257dd9 Merge branch dev-0222 into master
f6e93ea33 附加信息增加用户初始角色 1 file changed, 4 insertions()
18a44beef Merge branch dev-0206pro into master
1f3656121 息维护调整 1 file changed, 2 insertions(), 2 deletions(-)
...6.4 日志选项–graph
我们也可以通过–graph 选项来显示各提交之间的关系。 git log --graph --oneline
* 0a6f423df (HEAD - master, origin/master-l) ...
|\
| * 50498817d (origin/master, origin/HEAD) ...
| * 7cb257dd9 Merge branch dev-0222 into master
| |\
| | * f6e93ea33 附加信息增加用户初始角色
| |/
| * 18a44beef Merge branch dev-0206pro into master
| |\
| | * 1f3656121 息维护调整 7️⃣ 多次提交
新的提交未必一定得包含工作区中所发生的所有修改。事实上在这一方面Git 赋予了用 户完全的控制权。甚至我们可以用它来摘取合并其中的一些修改并将其纳入下一次提交中。 提交的产生通常被分为两个步骤。首先我们要用 add 命令将所有相关的修改纳入到一 个缓存区 (buffer) 中。这个缓存区通常被叫做暂存区 (staging area) 或索引 (index) 。 接着我们才能用 commit 命令将暂存区中的修改传送到版本库中。 7.1 status 命令
通过status命令我们可以查看当前工作区中所发生的修改以及其中的哪些修改已经被注册到了暂存区中以作为下次提交的内容。 git status# On branch staging
# Changes to be committed:
# (use git reset HEAD file... to unstage)
#
# modified:bar.txt
#
# Changed but not updated:
# (use git add file...to update what will be committed)
# (use git checkout --file...to discard changes in ...
#
# modified: foo.txt
#
# Untracked files:
# (use git add file...to include in what will be committed)
#
# new.txt
no changes added to commit(use git add and/or git commit -a)这段输出可按以下几个小标题来显示。
被提交的修改 (changes to be committed): 这部分将列出那些将在下次提交中被纳入版本库中的、被修改的文件。不会被更新的修改 (changed but not updated): 这部分将列出那些已被修改但尚未被注册到下次提交中的文件。未被跟踪的文件 (untracked files): 这部分将列出所有的新增文件。
除此之外Git 还提供了相关的帮助提示告诉我们应该用什么命令来重新改变这些状态。 例如我们可以用以下命令将 blah.txt 移出暂存区。
git reset HEAD blah.txt对于CVS 和 Subversion的用户来说“更新” 这个术语可能会引起一些用法上的混淆。在这些系统中“更新”通常指的是将版本库中所发生的修改回收到工作区中来。但在 Git 中更新则 是指将工作区中的修改集合到暂存区中两者的方向完全相反。 如果工作区中发生了很多修改我们也可以在此使用 --short 选项以便相关输出显得更紧凑一些。例如 git status --short
M blah.txt
M foo.txt
M bar.txt
?? new-file.txt由于创建新的提交未必就一定会包含当前所有的更新所以在这里我们可以选择纳入所有文件也可以只选取其中一些文件。 查看所发生的修改 git status在这里位于“不会被更新的修改”和“未被跟踪的文件”这两个小标题下的内容会被 status 命令显示为尚未被注册为下次提交的文件。 收集相关修改 接下来我们要用 add 命令将相关的修改添加到暂存区中。在这里我们既可以单独指定文件的路径也可以从其所有子目录中指定某一包含了新增文件与被修改文件的目录。 add 命令可以被调用多次并且允许我们在指定路径时使用 *和? 等通配符。 git add foo.txt bar.txt #selected filesgit add dir/ #a directory and everything underneathgit add. #current directory and everything underneath如果还想进行进一步的控制也可以在这里使用–interactive 选项开启交互模式。然 后就可以单独选取某个具体的代码片段了在极端的情况下我们甚至可以逐行将代码 注册到提交中。 创建提交 最后我们通过一次提交来启用这些修改。 git commit完成该操作后暂存区就会被清空。工作区将不受提交影响。那些没有被 add 命令添加的文件依然留在工作区中。
选择性提交对于某些修改之间的隔离非常有用。例如假设我们在项目中创建了一个新类 但与此同时我们也纠正了其他类中的一些错误。分多次提交这些修改有两个好处 一则是被提 交的历史记录更清晰二则使人们可以更方便地获取稍早前那个单一bug 的修复(即捡取)。
但我们需要记住的是选择性提交在版本库中所创建软件版本从未确实在本地存在过。 因此它们也从未测试过在最坏的情况下甚至都不能编译。综合上述原因我们会建议在可能的情况下尽量不要使用选择性提交。这种做法往往只能记录下我们想修复某个错误的信息但这并不等于它能正确地修复这个错误。 7.2 存储在暂存区中的快照
关于暂存区我们需要知道一件事它的作用并不仅仅是为下次提交提供一份文件清单。 暂存区不仅要存储修改所发生的位置同时也要存储修改的内容。为了达到这一目的Git 必须要为那些被选出的文件生成一个快照。下面我们以下图为例来为此做一个说明。在第1 行中工作区、暂存区以及版本库中的内容是相同的。然后开发者对其工作区中的文件做了某些修改(第2行)。再然后该开发者用add 命令将这些修改传到了暂存区中但版本库此时仍未受到影响(第3行)。 接下来到了第4行中开发者再次修改了文件。现在上述3个区域中的内容都不相同了。 然后我们用 commit 命令将第一次修改的内容传到版本库中(第5行号线)。这时候第二次修改的内容依然还留在工作区中。开发者需要继续通过add 命令将其转移到暂存区中来(第6行)。
我们所做的修改是通过 add 命令被注册到下次提交中的。在那之后当工作区中发生 进一步修改时我们就可以用diff 命令来一探究竟。
a. 暂存区中的是什么? 对于已经被 add 命令放入暂存区的那些修改我们可以通过 --staged 选项来显示器暂存 的内容。下面命令所要显示的是当前版本库中 HEAD 提交与暂存区之间的不同之处。 git diff --staged #staging vs.repositoryb. 尚未被注册的又是什么? 在不带任何选项的情况下 diff 命令所显示的就是工作区中尚未被注册的本地修改 换句话说就是显示暂存区与工作区之间的不同之处。 git diff #staging vs.workspace7.3 怎样的修改不该被提交
事实上有些特定的修改是我们确实不想提交的其中包括以下几种。
为调试而做的实验性修改。意外添加的修改。尚未准备好的修改。自动生成文件中所发生的修改。
reset 命令可用来重置暂存区。其 第一个参数为 HEAD, 表示的是我们 要将其重置为当前的 HEAD 版本。第 二个参数则用于指定要被重置的文件或目录。例如 git reset HEAD或者 git reset HEAD foo.txt src/test/在重置过程中暂存区将会被重写。这在通常情况下不会是一个问题 因为相同的修改很可能仍然会保留在 工作区中。但如果这个相同的文件在 add 命令之后已经被进一步修改过了那么相关信息就很可能被丢掉了。
对于上述问题Git 为我们提供了以下几种应对方法。
使用 reset 命令重置那些实验性的或者被意外修改的内容。将我们不希望被提交的忽略文件列表写入.gitignore。使用 stash 命令将我们希望日后再提交的修改内容暂时保存起来。 7.4 用.gitignore 忽略非版本控制文件
在一般情况下对于那些自动生成的文件、由编辑器创建的或用于备份的临时文件我 们不会希望将它们置于版本控制之下的。事实上我们可以通过往项目根目录下的 .gitignore 文件中添加条目的方式让Git “看不见” 这些文件。我们可以在该文件中指定这些文件路径和 目录并且可以使用 “*”和“” 等通配符。关于路径的指定我们需要知道即使我们在 该文件中写的是 generated/ 这样的简单路径也会将所有包含这一名字的目录都包括在内 例如 src/demo/generated, 都会被彻底忽略。但如果我们在这类路径之前加了个1, 例如 /generated/, 那么就只有这个确切的路径(相对于该项目的根目录而言)会被忽略了。
#
# Simple file path
#
somehow/simultaneous.txt
#
# Directories ending with a /
#
generated/
#
#File types as glob expressions
#
*.bak
#
# ! marked exceptions.demo.bak
# will be versioned,but *.bak
# will be excluded.
#
!demo.bak另外我们也可以在项目的子目录中创建一个.gitignore文件。这样一来该文件就只能影响该目录下的文件和路径了。这在某些情况下可能是有用的例如如果我们的项目是用 多种编程语言来编写的那么它们各自都应该有一个不同的配置文件。
但请注意.gitignore 文件中的条目只能影响那些当前还未交由Git 来管理的文件。如果 其中的某个文件已经被现有版本包含了那么 status 命令依然会显示该文件之上发生的所有 修改并且它也一样可以通过 add 命令被注册到下次提交中。如果我们想忽略一个已经被版本化的文件可以通过 update-index 命令的 --assume-unchanged 选项来做到这一点。
7.5 储藏
如果我们在某些事情进行到中间的时候突然发现自己需要快速修复某个问题。这时候 我们通常会希望立即着手去做相关的修改但同时先不提交之前一直在做的事情。在这种情况下我们可以用stash 命令先将这些修改保存在本地日后再来处理。
我们通过 stash 命令将工作区和暂存区中的修改保存在一个被我们称之为储藏栈 (stash stack) 的缓存区中。 git stash我们可以用 stash pop 命令将栈中所储藏的修改恢复到工作区中。
a. 恢复位于栈顶的被储藏修改 git stash popb1. 储藏堆栈中有什么? 首先我们要检查一下当前储藏了什么修改内容。 git stash list
stash{0}: WIP on master:297432e Mindmap updated.
stash{1}: WIP on omaster:213e335 Introduction to workflow b2. 恢复更早之前所储藏的修改 其次我们还是要检查一下当前栈中储藏了什么修改内容。 git stash pop stash{1}总结 版本库项目的版本库通常驻留在其.git 目录中。其中包含了以提交形式存储的项目历史。由于Git 是个分布式系统所以同一个项目通常可能会有多个拥有不同历史的版本库。按照 Git 的设计我们可以在必要时再将这些历史重新合并起来。 提交(通常也被称为版本、修订或修改集): 通过 commit 命令可以创建一次提交 一 次提交通常存储了项目的某种确定状态其中包含了该项目中所有文件的情况。每次提交中都包含了与作者和提交日期相关的元数据。特别地 Git中还存储了前/后提交之间的关系这种关系将构成一个项目版本图我们可以用 log 命令将版本库中的这些提交显示出来。 提交散列值提交散列值主要用于唯一标识提交。但同时它也是一种信息汇总我们 可以用它来验证软件对象的存储完整性。通常一个提交散列值的长度是40个字符。 暂存区暂存区(也称为索引)中所存储的是我们为下一次提交准备的内容它以快照的形式保存了相关的文件内容。 添加生成快照我们可以通过add 命令在暂存区中创建一份被修改文件的快照。这样 如果我们再次修改了同一批文件新增的修改就不会自动被纳入到下一次提交中了。 选择性提交我们可以用add 命令来指定哪些文件将会被存储在快照中其余所有文 件将保持不变。 代码段选取我们甚至可以通过 --interactive 选项来逐行(或者逐段)选取自己所需要的修改), 这种情况下只有被选取的那部分修改会以快照的形式被存储在暂存区中。 查看状态status 命令可以显示出哪些文件被纳入了下次提交而哪些文件只是在本 地本修改了还尚未被注册到暂存区中。 重置暂存区我们可以通过 git reset HEAD命令将所有文件重置到当前的HEAD 版本。 .gitignore 文件我们可以在这个文件中列出不需要被 Git 管理的文件目录。 储藏我们可以通过 stash命令将在工作区和暂存区中当前所做的修改储藏起来。之 后再用 git stash pop 命令将其恢复。 ⏪ 温习回顾上一篇点击跳转 《【Git教程】二入门 ——关于工作区与版本库、版本提交、查看信息、克隆、推送与拉回的简单介绍 ~》 ⏩ 继续阅读下一篇点击跳转 《》
