实验一 Git代码版本管理

实验目的：

1）了解分布式分布式版本控制系统的核心机理；

2)   熟练掌握git的基本指令和分支管理指令；

 

实验内容：

1）安装git

2）初始配置git ，git init git status指令

3）掌握git log ,git add ,git diff 指令

4) 掌握git tag git branch，git commit 指令

5）掌握git revert 指令

 

实验记录：

1.安装Git

2.初始配置

设置用户名，邮箱和使Git输出内容带有颜色标记

3.从头创建仓库

 创建项目目录

　　创建一个叫做 se2020-git-course的目录，在该目录中，创建另一个目录，叫做 new-git-project，使用 cd 命令移到 new-git-project 目录下然后使用 git init命令，新建一个空仓库。

 

 克隆现有仓库

　　首先需要验证终端所在的位置，在克隆任何内容之前都需要确保命令行工具已定位于正确的目录下。克隆项目会新建一个目录，并将克隆的 Git 仓库放在其中。问题是无法创建嵌套的 Git 仓库。因此，确保终端的当前工作目录没有位于 Git 仓库中。在 Git 上进行克隆的方法是调用我们将在终端上运行的命令 git clone，然后传入要克隆的 Git 仓库的路径。

 

 判断仓库状态

　　git status 是了解 Git 的核心所在。它将告诉我们 Git 正在考虑什么，以及 Git 所看到的我们仓库的状态。这样可以帮助你了解 Git 的工作原理，并避免对文件 / 仓库状态做出不正确的推论。利用 git status 命令来随时查看当前仓库的状态。

 4.git log

git log 命令用于显示仓库中所有 commit 的信息。默认情况下该命令会显示仓库中每个 commit 的：SHA、作者、日期、消息等。

 

git log --oneline命令

　　我们可以使用 git log --oneline 命令以不同的格式风格来代替 git log 的输出，相比较而言 git log --oneline的输出结果更为简短并且可以节省大量空间。

　　git log --oneline命令的显示格式通常为：

　　每行显示一个 commit

　　显示 commit 的 SHA 的前 7 个字符

　　显示 commit 的消息

 

git log --stat命令

　　git log --stat命令可以用来显示 commit 中更改的文件以及添加或删除的行数。

　　git log --stat命令的显示格式通常为：

　　显示被修改的文件

　　显示添加/删除的行数

　　显示一个摘要，其中包含修改/删除的总文件数和总行数

 

 查看更改　

git log -p 命令

　　git log -p 命令是一个可用来显示对文件作出实际更改的命令。( -p 是 --patch 的简写)。

　　git log -p 命令通常会向默认的输出中添加以下信息：

　　显示被修改的文件

　　显示添加/删除的行所在的位置

　　显示做出的实际更改

 

 git show 命令

　　上一部分的最后几个练习需要在补丁（修改）输出中不断向下滚动，以便找到正确的 commit 并查看其信息。通过提供 SHA，git log -p 命令将从这条 commit 开始！无需滚动并逐条查阅！注意，它还会显示在所提供的 SHA 之前提交的所有 commit 信息。

　　git show 命令将仅显示一个 commit。因此，如果你看不到任何其他 commit，不要惊慌。它只显示一个 commit。git show 命令的输出和 git log -p 命令的完全一样。因此默认情况下，git show 会显示：

• commit

• 作者

• 日期

• commit 消息

• 补丁信息

（例如：git show fdf5493）

 

 5.git add& git commit&git diff

添加新文件，并使用git status 检查状态

在new-git-project里 创建 index.html 文件，添加代码；建立 js 和css 文件夹，并在文件下分别建立 app.js 和 app.css 文件.

git status检查状态

 

 暂存文件

 在终端上运行git add命令将 index.html 添加到暂存区，并使用git status检查状态

 

 暂存剩余的文件

index.html 文件已暂存。我们再使用git add css/app.css js/app.js命令暂存另外两个文件，并检查状态

 git commit 命令

使用 git commit 命令将暂存区中的文件进行提交。

 

 

 git commit 小结：

git commit 命令会取出暂存区的文件并保存到仓库中并打开配置中指定的代码编辑器。

在代码编辑器中：

• 必须提供提交的文字说明，记录或解释所做的修改
• 以 # 开头的行是注释，将不会被记录
• 添加提交说明后保存文件
• 关闭编辑器以进行提交

git diff

git diff 命令可以用来查看已被加入但是尚未提交的更改。在 index.html 中添加两个

标签，保存文件，然后在终端上运行 git diff。

git diff 小结：

git diff 命令用来查看已经执行但是尚未 commit 的更改，此命令会显示：

• 已经修改的文件
• 添加/删除的行所在的位置
• 执行的实际更改

6.标签、分支

git tag标签

git tag 命令可以为 commit 添加标签，运行 git tag -a v1.0 命令打开代码编辑器，输入信息，保存退出

创建标签

进入news-git-project，输入git tag 命令，使用 git tag 命令与仓库的标签进行交互，上述命令将打开代码编辑器，并等待你为标签输入信息。我们输入"Ready for content"作为tag。

验证标签
保存并退出编辑器后，命令行上什么也不会显示。那么如何知道已经向项目中添加了标签呢？只需输入 git tag，命令行会显示仓库中的所有标签。

 

 

 

 查看标签

使用 git log 命令查看标签位于仓库的哪个位置。

 

 删除标签：

可以通过输入 git tag -d 命令来删除错误的标签名

 

git tag 小结

• 向最近的 commit 添加标签

• 如果提供了 SHA，则向具体的 commit 添加标签

 git branch分支

创建分支：我们只需要使用 git branch 命令并提供要创建分支对应的名称。但是同时需要注意的是新创建的分支它不是当前系统分支。提示符显示的才是当前分支master。要使用新创建的 sidebar 分支，我们需要使用 git checkout 命令手动的切换到该分支。以创建 sidebar 的分支为例

 

活跃分支

提示符将显示活跃分支。但这是我们对提示符进行的特殊自定义，如果你使用的是不同的计算机，判断活跃分支的最快速方式是查看git branch 命令的输出结果。

 

 删除分支

如果我们不再需要某个分支时我们可以使用 git branch -d 命令来完成。

7.合并

 合并分支

git 可以自动将不同分支上的更改合并到一起。可以在分支上做出小的或大的更改，然后使用 git 合并这些更改。

发生合并时，git 将：

• 查看将合并的分支

• 查看分支的历史记录并寻找两个分支的 commit 历史记录中都有的单个 commit

• 将单个分支上更改的代码行合并到一起

• 提交一个 commit 来记录合并操作

 

 合并冲突

git 会跟踪文件中的代码行。如果完全相同的行在不同的文件中更改了，将产生合并冲突。大部分情况下，git 将能够成功地合并分支。但是，有时候 git 无法完全自动地进行合并。合并失败时，就称为合并冲突。

git 使用合并冲突指示符来告诉你两个不同分支上的哪些行导致了合并冲突，以及原始行是什么

 

 合并冲突小结

当相同的行在要合并的不同分支上做出了更改时，就会出现合并冲突。git 将在合并途中暂停，并告诉你存在冲突，以及哪些文件存在冲突。要解决文件中的冲突：

• 找到并删掉存在合并冲突指示符的所有行

• 决定保留哪些行

• 保存文件

• 暂存文件

• 提交 commit

8.撤销更改

git commit --amend命令

可以对最近一个提交的 commit 进行更改，重新提交commit 消息

 

 

 

还原 commit

当你告诉 git 还原（revert） 具体的 commit 时，git 会执行和 commit 中的更改完全相反的更改。

 

 

git revert 命令

当我们创建了一个包含一些更改的 commit，我们可以使用 git revert 命令来还原它。

 

 git reset 命令

git reset命令用来重置（清除）commit

可以用来：

• 将 HEAD 和当前分支指针移到目标 commit

• 清除 commit

• 将 commit 的更改移到暂存区

• 取消暂存 commit 的更改

 

 

实验总结与体会:

对于本次实验，整个过程也算比较顺利，刚开始觉得挺复杂但慢慢做过几节后对整个Git系统对版本管理的流程有了大致的掌握，后续实验做的比较顺利，题目也没有再错了。配置编辑器的时候出了一些问题，后来commi实验的时候编辑器调不出来，结果是配置的时候编辑器路径输错了，导致配置失败。对于本次实验还要通过课后的进一步巩固和理解整个实验内容。

思考题：

阅读维基百科和百度百科 的Git词条，总结分布式分布式版本控制系统的核心机理

　　分布式版本控制系统是一种有效、高速地处理从很小到非常大的项目版本管理系统。与它相对的是集中式版本控制系统。在分布式版本控制系统中客户端并不像集中式版本控制系统那样提取最新版本的文件快照，而是把代码仓库完整地镜像下来。这样的核心机理就轻松的解决了集中式版本控制系统中容易出现的也是很致命的中央服务器单点故障。分布式版本控制系统没有所谓的"中央服务器"，每个人的电脑上都是一个完整的版本库。通常分布式版本控制系统有一台"伪中央服务器"，但是这个服务器的作用仅仅是用来方便"交换"大家的修改，没有它大家仍然可以正常工作。