目的：
1）分散型バージョン管理システムのコアメカニズムを理解します。
2）gitのマスター基本命令と分岐管理命令。
実験：
1）gitのインストール
2）初期設定のgit、gitの初期化gitのステータスコマンド
3）マスターgitのログ、gitの追加、gitのdiffコマンド
4）マスターgitのタグGitのブランチ、gitのコマンドをコミット
5）マスターのgit revertコマンド
実験記録：
1）実験内容及び結果スクリーンショット。
2）問題は、実験中に発生し、解決します。
gitのをインストールします。1.
ダウンロードの窓は、ソフトウェアのバージョンをgitの、gitのをインストールし、インストール後にすべてのデフォルトオプションを選択し、使用状況の情報を表示することができ、デスクトップスペースを右クリックして、インストールが成功しました。
2.初期設定のgit
2.1第一の構成のGit（セットユーザー名、Eメール、色の出力の内容、コントラスト表示することを元の状態を確保します）
2.2gitとコードエディタ（この選ばれた崇高なテキストエディタ）
倉庫の作成3.
3.1プロジェクトディレクトリを作成します
ディレクトリを作成します。次の新しい-のgit-プロジェクトディレクトリに移動し、cdコマンドを使用して、新しい-gitのプロジェクト：se2020-のgit-もちろん、このディレクトリ内に、別のディレクトリを作成します。（デスクトップ見える新しいフォルダに）
gitの初期化を実行し、現在のディレクトリに初期化空のGitリポジトリを生成します。（フォルダ選択 - >表示 - >あなたは.gitフォルダを見ることができ、表示隠された項目を確認してください）
3.2既存の倉庫のクローンを作成
、端末は現在の作業ディレクトリのGitリポジトリにないことを確認してくださいコマンドgitのクローンを入力し、[Gitリポジトリをクローン化するためにパスを入力し、本試験パスします。https：//github.com/udacity/course-git-blog-project （現在のディレクトリは、次のとおりです。se2020-gitのコース）
倉庫3.3の状態を解析
コマンドを使用します。gitの状態を、リポジトリとGitリポジトリの状態を検討しているかを示すことができます。（現在、新しい-gitのプロジェクトで）
由于没有实施任何操作，此目录为空目录，所以显示没有已提交信息，也没有任何待定的修改。
思考：如何证明此仓库尚无任何commit？
运行命令git log，结果显示does not have any commits。
4.git log
git log 命令用于显示仓库中所有 commit 的信息。默认情况下该命令会显示仓库中每个 commit 的：SHA、作者、日期、消息等。
4.1git log --oneline命令
git log --oneline,可以用来更改仓库信息的显示方式。（由于当前只提交了两个文件，显示的信息只有两条）
其中显示格式为：
-
每行显示一个 commit
-
显示 commit 的 SHA 的前 7 个字符
-
显示 commit 的消息
4.2git log --stat命令
git log --stat，用来显示 commit 中更改的文件以及添加或删除的行数。
此命令会：
-
显示被修改的文件
-
显示添加/删除的行数
-
显示一个摘要，其中包含修改/删除的总文件数和总行数
4.3git log -p 命令
git log -p 命令可用来显示对文件作出实际更改的命令。（在对文件进行各种操作后）
此命令会：
-
显示被修改的文件
-
显示添加/删除的行所在的位置
-
显示做出的实际更改
4.4git show 命令
a.向git log 提供要查看的commit 的SHA，将从这条 commit 开始！无需滚动并逐条查阅！注意，它还会显示在所提供的 SHA 之前提交的所有 commit 信息。
b.使用git show命令，将显示最近的commit（只有一个）。
其中git show 可以与其他选项一起使用：
-
--stat 显示更改了多少文件，以及添加/删除的行数
-
-p 或--patch 显示默认补丁信息
-
-w 忽略空格变化
5.git add& git commit&git diff
5.1 新建文本
a.进入new-git-project创建HTML文件，添加一些起始代码.
b.建立 js 和css 文件夹，并在文件下分别建立 app.js 和 app.css 文件，文件内容为空
c.输入命令git status，查看当前状态
从输出结果中可以看出，新建的三个文件没有被git跟踪。
5.2 git add
使用 git add 将 index.html 添加到暂存区，再用get status查看当前状态。
可以看出index.html已位于暂存区。
暂存另外两个文件可输入：git add css/app.css js/app.js或者git add .
5.3 git commit
使用git commit命令，来提交commit。（当前已配置好 subline text编辑器）
编辑器自动打开后界面为：
在编辑器首行输入：Initial commit,保存文件并关闭编辑器窗口，回到终端，可以看见：
5.4 使用 -m 选项绕过编辑器
a.在index.html 中的body标记中加入<header> <h1><Expedition></h1></header>
b.运行git status(显示了index.html修改后的文件）
c.用 git add 命令将文件移到暂存区，并使用 git status 验证文件是否位于暂存区。(结果显示此文件已位于暂存区）
d.使用 git commit 命令提交 commit，并添加提交说明。
e.使用git log 检查刚刚提交的commit。
5.5 git diff
此工具可以在进行提交之前告诉我们已对文件进行了什么样的更改。
此命令会显示：
-
已经修改的文件
-
添加/删除的行所在的位置
-
执行的实际更改
例：用git diff 命令来查看已加入但是尚未提交的更改。在index.html中将标题改为Adventure，保存后在终端上运行git diff。结果显示为：
5.6 gitignore
因为git add .会添加所有文件，当想将某个文件留在项目中的目录结构中，但是确保它不会意外地提交到项目中，可以用特殊文件名.gitignore，将此文件添加到项目的根目录中，列出希望git ignore 的文件名，git将忽略这些文件。
a.建立word文件project.docx：用touch .gitignore命令生成.gitignore文件，并将此文件名保存在.gitignore文件中。
b.运行git status命令，查看输出结果：
可以看出word文档不再列为未跟踪文件，但列出了新的'.gitignore'文件。
6.标签、分支
6.1git tag 标签
6.1.1创建标签
a.进入new-git-project项目文件夹中，使用git tag命令与仓库的标签进行交互，输入：git tag -a v1.0
b.系统自动打开代码编辑器，在第一行输入"Ready for content"作为tag。
6.1.2验证标签
保存并退出编辑器后，回到终端界面，输入git tag显示仓库中的所有标签。
使用git log，可查看该标签位于仓库的哪个位置。（2.13版本中git log --decorate与其结果一致）
6.1.3删除标签
可以通过输入 -d 选项加上标签名称来删除 git 标签。例：git tag -d v1.0将之前建的标签删除了。
6.1.4向以前的commit添加标签
只需提供要添加标签的 commit 的 SHA，即可向仓库中很久之前的 Commit 添加标签。其中可以通过查询历史SHA git log --oneline，查找已经commit 的SHA。
例：查询已commit的SHA为：
向 SHA 为dac1263的 commit 添加标签v1.0
6.2git branch分支
6.2.1git branch命令（用来与git的分支进行交互）
可以用来：列出仓库中的所有分支名称；创建新的分支；删除分支
例：结果显示了master分支
6.2.2创建分支
使用git branch ，并提供要创建的分支对应的名称。
例：创建一个名为“sidebar"的分支。
使用 git 的checkout命令，在分支间进行切换。
查看git log的输出结果，来显示分支。
其中：特殊指示符“HEAD"指向当前分支”sidebar",现在提交的任何 commit 将添加到 sidebar 分支。
6.2.3活跃分支
提示符将显示活跃分支。用git branch命令快速判断活跃分支，其中活跃分支名称旁边会显示一个星号。
6.2.4删除分支
可以使用-d选项，删除分支。（大写的D，可以进行强制删除）
例：删除之前创建的分支“sidebar”，由于无法删除当前分支，所以要先切换到master分支再删除。
6.3高效分支
在new-git-project项目中，按照实验内容修改index文件内容，然后删除前面建好的 siderbar 分支、所有文件暂存并提交到仓库、切换到master分支、运行git status
由于之前已经将sidebar分支删除，这里找不到此分支无法删除
6.4分支实战
a.添加页面颜色
b.添加侧栏
由上图选择SHA为8862b05，并建立sidebar分支；
切换到sidebar分支上；
运行git log --oneline --decotate命令
结果显示：在master分支提交的“Set backageround color for page" commit 没有了；
打开css/app.css，发现文件为空。
向index.html文件中添加<aside>代码，commit index.html
c.更改master上的标签
切换到master分支上；修改index.html标题；commit index.html；用git log --oneline 检查
d.同时查看所有分支
7.合并（将分支组合到一起）
7.1合并指令 git merge
在master分支上，运行：git master sidebar命令；提交commit（直接使用默认的合并commit消息）
7.2合并冲突（合并失败时）
如果完全相同的行在不同的文件中更改了，将产生合并冲突。
人为制造合并冲突：例在两个不同的分支上更改同一页面的标题。
a.更改master分支标签，后commit
b.创建一个heading-update分支，使用git --oneline --graph --all查看
c.切换到heading-update分支，更改index.html的标签为：crusade,然后commit
d.切换到master分支，合并分支，产生冲突
e.使用git status命令查看
此时打开编辑器查看文件，可以发现文件中出现合并冲突指示符，提示了冲突的信息。
7.3解决合并冲突
a.根据冲突指示符，要选择保留的行还要删除所有带指示符的行。保存后commit（使用默认的commit信息）
8.撤销更改
8.1更改最后一个commit
使用git commit --amend可以更改最近的commit，代码编辑器会自动打开，可修改commit消息。
8.2还原（revert）commit
a.将某个commit改为Quests & Crusades
b.还原commit（最近的commit的SHA为6872b66)
8.3重置（会清除commit）
可以用来：
-
清除 commit （使用--hard)
-
将 commit 的更改移到暂存区 (使用 --soft)
-
取消暂存 commit 的更改 (使用 --mixed)
- 将 HEAD 和当前分支指针移到目标 commit
例：
从结果中可以看见：commit ffe2e04中做出的更改移至工作目录中。
8.4备份分支
先创建一个backup分支用于备份，当重置操作出现错误时，返回这些commit即可。
让master分支指向backup分支所指向的同一commit。（删除未commit的更改，backup合并到master）
实验总结与体会：
总结（遇到的困难与解决）：
1.由于之前对git几乎不了解，不知道git的功能与作用是什么。在一开始实验时，即使跟着操作步骤能完成相关命令，但并没有了解其真正实现的是什么，效率低下。
所以我在实验开始阶段，上网找了更多相关视频，听了别人对git的分析，了解git的历史和在生活中的实际意义，知道git软件的基本使用方法，所以在实验过程中较为顺利，提高了效率。
2.对git的命令记不住，分不清。一开始感觉git命令很多很杂，之前用了很快就忘记了，下次使用时又要花时间找之前的操作步骤。还有些命令书写相似，功能相似，有些时候分不清到底又哪一个比较合适。有时候知道某个命令的作用，但在特定场合却想不起来去用它。有些命令会报错，但报错后要花大量时间才能找到原因。
所以我每次使用一个新的命令就记录下来，对经常会使用到的命令多加记忆。详细了解每个命令的作用，分清命令的功能，可以实际操作根据现实结果来区分不同的命令。对于报错的命令，先根据提示查询原因来解决，还是解决不了的上网找寻答案，对于特殊的错误记录下来，防止下次再出现。
3.由于实验是经过多次操作完成的，当下一次开始时，就会忘记自己做了哪些操作。一开始只知道几个简单的命令，在出现操作错误时，不知道怎么返回只能重新打开git，重新开始，浪费了很多时间。
由于有些命令会影响后面的命令的执行，所以我尽可能将每一小节一起完成。每一次开始试验时，先使用git status 来查看当前状态，了解之前做了哪些操作，为后面的试验做准备。在后面了解了更多的命令后，在提交错误信息时可以撤销，而不用重新修改提交等，节省了很多时间。
体会：
在做实验之前，因为对git不了解很怕自己不会做，在做实验过程中出现错误解决不了时，会懊恼明明命令正确却执行不成功，在解决错误上花费了很多时间。但在完成实验后，再一步步看之前的操作，发现实验并不是很难。面对未知的知识，要有好奇心和探索欲，出现错误后及时寻找原因，在错误中我们能学习到更多。
思考题：
阅读维基百科和百度百科的Git词条，总结分布式版本控制系统的核心机理
答：分布式版本控制系统是一种有效、高速地处理从很小到非常大的项目版本管理系统。与它相对的是集中式版本控制系统。在分布式版本控制系统中客户端并不像集中式版本控制系统那样提取最新版本的文件快照，而是把代码仓库完整地镜像下来。这样的核心机理就轻松的解决了集中式版本控制系统中容易出现的也是很致命的中央服务器单点故障。分布式版本控制系统没有所谓的"中央服务器"，每个人的电脑上都是一个完整的版本库。通常分布式版本控制系统有一台"伪中央服务器"，但是这个服务器的作用仅仅是用来方便"交换"大家的修改，没有它大家仍然可以正常工作。