实验一 GIT 代码版本管理

实验一  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并进行初始配置

1.1 初次配置Git

       在开始使用 Git 之前，要进行初始配置 ，如下设置用户名和邮箱等基础配置。

2. 创建仓库 

2.1 克隆实验所需仓库

       在对 Git 仓库进行 commit 或执行任何其他操作之前，需要一个实际存在的仓库，首先创建一个目录，叫做 se2020-git-course，在该目录中，创建另一个目录，叫做 new-git-project，使用 cd 命令移到 new-git-project 目录下，然后使用 git init命令，新建一个仓库。

       克隆实验所需仓库，输入命令 git clone，然后输入克隆的 Git 仓库的路径，实验使用以下 URL ：https://github.com/udacity/course-git-blog-project 。

2.2 判断仓库状态

       git status 是了解 Git 的核心所在，它将告诉我们 Git 正在考虑什么，以及 Git 所看到的我们仓库的状态，运行此命令结果如下图所示： 

        git status 作用：

       git status 命令将显示很多信息，具体取决于你的文件状态、工作目录和仓库。但是你不需要过于关心这些内容…只需运行 git status，它将显示你需要知道的信息。

输出结果告诉了我们几条信息：

• On branch master – 这部分告诉我们 Git 位于 master 分支上，（也就是默认分支）。
• Your branch is up-to-date with 'origin/master'. – 因为我们使用 git clone 从另一台计算机上复制了此仓库，因此这部分告诉我们项目是否与所复制的仓库保持同步状态。我们不会在其他计算机上处理该项目，因此这一行可以忽略。
• nothing to commit, working directory clean – 表示没有任何待定的更改。

3. commit 的提交

3.1 git log  

       git log 命令用于显示仓库中所有 commit 的信息，默认情况下，该命令会显示仓库中每个 commit 的SHA，作者，日期，消息，运行结果如下图：

3.1.1 git log --oneline

       有时候我们并不关心 commit 的时间，我们希望隐藏这一信息，使输出结果更简短，并节省大量空间，而git log --oneline 命令可以帮助我们。

git log --oneline的作用：

• 每行显示一个 commit
• 显示 commit 的 SHA 的前 7 个字符
• 显示 commit 的消息

运行结果如下图：

3.1.2 git log --stat

       git log 命令有一个选项可以用来显示 commit 中更改的文件以及添加或删除的行数，该选项为 --stat（stat 是“统计信息 statistics”的简称）

git log --stat 的作用：

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

运行结果如下图：3.1.3 git log -p

       git log 命令具有一个可用来显示对文件作出实际更改的选项。该选项是 --patch，可以简写为 -p

git log -p 的作用：

• 显示被修改的文件
• 显示添加/删除的行所在的位置
• 显示做出的实际更改

运行结果如下图：

       也可通过 git log -p + SHA命令控制显示的起始位置，通过提供 SHA，git log -p 命令将从这条 commit 开始，无需滚动并逐条查阅，显示该条 commit 的更改信息，它还会显示在所提供的 SHA 之前提交的所有 commit 信息。

3.2 git show 

       git show 命令将仅显示一个 commit，git show 命令的输出和 git log -p 命令的完全一样。运行结果如下图：

      git show小结：

• SHA
• 作者
• 日期
• commit 消息
• 补丁信息  

3.3 git add 

       进入到 new-git-project，首先创建一个叫做 index.html 的文件，并添加一些起始代码，然后建立 js 和css 文件夹，并在文件下分别建立 app.js 和 app.css 文件，文件内容为空，接下来使用 git status 检查状态，运行结果如下图：

       使用 git add 将 index.html 以及其他文件添加到暂存区，并再次检查状态，运行结果如下图：

3.4 git commit

       接着提交 commit， 使用 git commit 命令，运行这条命令将会打开之前配置的代码编辑器 Sublime Text，输入commit 信息，保存关闭即可，运行结果如下图：

       继续提交第二个 commit ，在 index.html 中的 body 标签中添加如下代码：

       保存更改，运行 git add index.html 将文件提交到暂存区，使用 git status 查看状态，可以看到文件已在暂存区，运行 git commit 命令并添加提交说明 Add header to blog，运行结果如下图： 

       使用 git log 检查刚刚提交的 commit ，运行结果如下图：

      git commit 小结：

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

在代码编辑器中：

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

3.5 git diff

       git diff 命令可以用来查看已被加入但是尚未提交的更改。在 index.html 中添加两个<div>标签，保存文件，然后在终端上运行 git diff。运行结果如下图：

      git diff 小结：

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

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

3.6 gitignore

       如果我们向项目所在目录添加了一个 Word 文档等文件，但是不希望将该文件添加到仓库中。git 会看到这个新文件，并且运行 git status 时，它将显示在文件列表中。如下图所示：

       因为 git add . 会添加所有文件，因此该 Word 文档可能会不小心 commit 到仓库。我们可以用 .gitignore（注意文件名开头的点不能忽略）确保它不会意外地提交到项目中。将  project.docx 文件添加到 new-git-project 项目根目录。将 "project.docx” 代码添加到 .gitignore 文件中，git 将忽略这些文件。现在运行 git status 并查看输出结果：

       Word 文档已不再列为未跟踪文件(untracked files )。但是列出了新的".gitignore"文件。git 知道查看名称为 .gitignore 的文件的内容。因为它在其中看到"project.docx"，所以忽略了该文件，并且没有在 git status 的输出结果中显示该文件。

4. 标签、分支与合并

4.1 git tag

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

       不使用 -a 选项只会添加一个轻量级标签，使用 git tag + SHA 可以为指定 commit 添加标签信息，运行结果如下：

       如果标签信息有错误，可以通过输入 -d 选项加上标签名称来删除 git 标签。

      git tag 小结

• 向最近的 commit 添加标签

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

4.2 git branch

• 在 master 分支上 - 向页面添加默认颜色。

• 创建一个 sidebar 分支 - 为页面创建侧栏。

•  在 master 分支上 - 更改页面的标题。

•  在 sidebar 分支上 - 向侧栏中添加更多内容。

4.3 git merge 

       合并分支结果如下：

      合并小结：

• 快进合并 – 要合并的分支必须位于检出分支前面。检出分支的指针将向前移动，指向另一分支所指向的同一 commit。

• 普通类型的合并

• 两个完全不同的分支被合并

• 创建一个合并 commit

4.4 分支冲突

• 在master分支上更改标题。

•  在上一个 commit 上创建新分支，并在该分支上更改标题。

•  回到 master 分支，合并分支，冲突出现，结果如下图所示：

•  此时需要人为选择保留一个更改，结果如下：

5. 撤销更改

5.1 git commit --amend 

       该命令可以对最近一个提交的 commit 进行更改，重新提交commit 消息，注意是更改并不会创建新的 commit 。

5.2 git revert 


       使用 git revert df80b36 将该条 commit 所做的修改撤消，并创建一个新的 commit 来记录这一更改，运行结果如下。

5.3 git reset 

       使用 git reset 命令将清除当前分支上的 commit，运行结果如下：

      git reset 总结：

• 将 HEAD 和当前分支指针移到引用的 commit
• 使用 --hard 选项清除 commit
• 使用 --soft 选项将 commit 的更改移至暂存区
• 使用 --mixed 选项取消暂存已被 commit 的更改

实验中的问题和总结：

       1. 总的来说本次实验不难，整个过程也算比较顺利，刚开始觉得挺复杂的，在做第一步的时候，对暂存区、commit，仓库等这些概念讲解看的不是很仔细，导致第一个题目做错了，然后我就回过头继续看老师讲解，发现了问题所在，之后做的更加仔细，慢慢做过几节后对整个Git系统对版本管理的流程有了大致的掌握，后续实验做的比较顺利，题目也没有再错了。

       2. 配置编辑器的时候出了小问题，后来进行commi实验的时候发现编辑器调不出来，经过检查原来配置的时候编辑器所在路径打错了一个字母，导致配置失败，虽然是个小问题，但也反映了我的粗心大意，如果以后一个大项目出了点这样的问题查找起来就不简单了，这里也想问下如果Git能对每条命令都给出一些反馈不是更好吗，感觉软件开发过程中阶段性测试确实很重要。

       3. git status对初学者很有帮助，在刚开始不熟悉整个系统时候多使用这条命令，可以有效地帮助你少走弯路，节省实验时间，能够帮助你快速了解Git的工作原理。

       4. 分支是个极其好用的东西，在做这部分实验之前我就在想如果我们想把做过的更改撤销，我想应该会有撤销更改的方法，但是如果想对这个项目做一个大的改动，又不知道结果是否令人满意，而大的改动应该会伴随着很多commit，如果结果不好，难道只能一条一条撤销吗，或者有连续撤销多条commit的方法？学到分支的时候我豁然开朗，并感叹开发者的设计之巧妙，有点像单机游戏的回档，有意思。

思考题：

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

        Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件，是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。分布式的版本控制就是每个人都可以创建一个独立的代码仓库用于管理，在自己的机器上根据不同的开发目的，创建分支，修改代码，提交代码，并通知所有开发人员，速度更快、更灵活，两个开发者之间的冲突也更容易解决。

（天下程序猿是一家，在下初学Git，如果有写的不对的地方，还请阁下不吝赐教，感激不尽）