zoukankan      html  css  js  c++  java
  • 实验一

    实验目的:

    (1)了解分布式版本控制系统的核心机理;

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

    实验内容:

    (1)安装git;

    (2)初始配置git,git init,git status指令

    (3)掌握git log,git add,git diff指令;

    (4)掌握git revert指令;

    实验记录:

    配置用户名邮箱

           在第一次使用GIT之前,必须先配置相关的信息,由上至下依次为用户名,邮箱,输出内容带有颜色标记,对比显示原始状态,相关信息(用户名邮箱之类的设置)列表,编译器设置

    创建仓库,克隆仓库

           这里创建了2个名目录,一个名为se2020-git-course-project且在这个目录下又创建了一个名为new-git-project的目录进入该目录,此时在此目录下使用命令git init

    终端会显示 git init 命令正在运行。该命令会在当前目录下初始化生成一个空的 Git 仓库。

          

           在 Git 上进行克隆的方法是调用我们将在终端上运行的命令 git clone,然后传入要克隆的 Git 仓库的路径(通常是 URL)。

    首先需要验证终端位置,在克隆任何内容之前,确保命令行工具已定位于正确的目录下。克隆项目会新建一个目录,并将克隆的 Git 仓库放在其中。问题是无法创建嵌套的 Git 仓库。因此,确保终端的当前工作目录没有位于 Git 仓库中。如果当前工作目录没有在 shell 的提示符中显示,输入 pwd 输出工作目录。

    判断仓库状态

           克隆后的仓库状态

           git status 是了解 Git 的核心所在。它将告诉我们 Git 正在考虑什么,以及 Git 所看到的我们仓库的状态。当你第一次使用 Git 时,你应该一直都要使用 git status 命令.你应该习惯于运行任何其他命令之后,都运行下该命令。这样可以帮助你了解 Git 的工作原理,并避免你对文件 / 仓库状态做出不正确的推论。

     git log

          git log 命令用于显示仓库中所有 commit 的信息。

          git clone --oneline 命令:

          1、每行显示一个 commit

          2、显示 commit 的 SHA 的前 7 个字符 

          3、显示 commit 的消息

     git log --stat 

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

        git log -p

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

        git show 

        git show 命令将仅显示一个 commit。默认情况下,git show 会显示:commit、作者、日期、commit 消息、补丁信息 

    git add& git commit&git diff

         准备工作

        1)创建 HTML 文件

              首先,创建一个叫做 index.html 的文件,并添加一些起始代码 

        2)建立 js 和css 文件夹,并在文件下分别建立 app.js 和 app.css 文件,文件内容可为空

                  此时仓库状态:

      暂存文件

        在终端上运行以下命令,使用 git add 将 index.html 添加到暂存区:$ git add index.html

                  运行该命令及仓库状态如下:

                继续暂存文件:

                  git commit  

          要在 git 中提交 commit,需要使用 git commit 命令

          运行结果如下:

    提交添加更改后的commit

      向index.html中的body提交如下内容:

      <header>

         <h1>Expedition</h1>

      </header>

      运行git status命令,查看此时状态

    git diff

      使用git diff命令用来查看已经执行但是尚未 commit 的更改:

      此命令会显示:  

      已经修改的文件

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

      执行的实际更改

    gitignore

      如果你想将某个文件保留在项目的目录结构中,但是确保它不会意外地提交到项目中,可以使用名称特殊的文件 .gitignore(注意文件名开头的点,很重要!)。

      将此文件添加到 new-git-project项目根目录。你只需列出希望 git ignore(忽略,不跟踪)的文件名,git将忽略这些文件。

      我们用"project.docx"文件试一下。

     

      将以下行添加到 .gitignore 文件中:

      project.docx

      现在运行 git status 并查看输出结果:

      终端显示了 git status 的输出结果。Word 文档已不再列为未跟踪文件(untracked files )。但是列出了新的".gitignore"文件。

      git 知道查看名称为 .gitignore 的文件的内容。因为它在其中看到"project.docx",所以忽略了该文件,并且没有在 git status 的输出结果中显示该文件。

    忽略文件名中的通配符

      通配符允许你使用特殊的字符来表示某些格式/字符。在 .gitignore 文件中,你可以使用:

    • 空白行作为空格

    • # - 将行标记为注释

    • * - 与 0 个或多个字符匹配

    • ? - 与 1 个字符匹配

    • [abc] - 与 a、b 或 c 匹配

    • ** - 与嵌套目录匹配 - a/**/z 与以下项匹配

      • a/z

      • a/b/z

      • a/b/c/z

    标签分支

          git tag

        我们将使用 git tag 命令与仓库的标签进行交互,输入以下命令

       git tag -a v1.0

    上述命令将打开代码编辑器,并等待你为标签输入信息。我们输入"Ready for content"作为tag。

         在上述命令 (git tag -a v1.0) 中,使用了 -a 选项。该选项告诉 git 创建一个带注释的标签。如果你没有提供该选项(即 git tag v1.0),那么它将创建一个轻量级标签。

        建议使用带注释的标签,因为它们包含了大量的额外信息,例如:

    标签创建者

        标签创建日期

        标签消息  

        如果将标签消息中的某个字打错了,或标签名称打错了(输入 v0.1,而不是 v1.0),如何修正这个错误?最简单的方法是删除这个标签并重新创建。

        可以通过输入 -d 选项 (表示 delete 删除!)加上标签名称来删除 git 标签:

        $ git tag -d v1.0

    git tag 小结

    总结下,git tag 命令用来标记特定的 commit 。当添加新的 commit 时,标签不会移动。

    $ git tag -a beta

    此命令将:

    • 向最近的 commit 添加标签

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

    git branch 分支

      

    git branch 命令

      git branch 命令用来与 git 的分支进行交互:

      $ git branch
      它可以用来:

        列出仓库中的所有分支名称

        创建新的分支

        删除分支

    创建分支

      要创建分支,只需使用 git branch 并提供要创建的分支对应的名称。因此,如果你想创建一个叫做"sidebar"的分支,只需运行以下命令:

      $ git branch sidebar

    git checkout 命令

          注意,在进行 commit  时,该 commit 将添加到当前分支上。虽然我们创建了新的 sidebar 分支,但是没有向其添加新的 commit,因为我们尚未切换到该分支。

          如果我们现在进行 commit 的话,该 commit 将添加到 master 分支,而不是 sidebar 分支。我们已经在演示中看到这一情况,要在分支之间进行切换,我们需要使用 git 的 checkout 命令。

    活跃分支

         提示符将显示活跃分支。但这是我们对提示符进行的特殊自定义

       如果你使用的是不同的计算机,判断活跃分支的最快速方式是查看 git branch 命令的输出结果。活跃分支名称旁边会显示一个星号。

    删除分支

      分支用来进行开发或对项目进行修正,不会影响到项目(因为更改是在分支上进行的)。

      在分支上做出更改后,你可以将该分支组合到 master 分支上(这种“分支组合过程”叫做“合并”(merge),稍后将详细讲解)

      合并了分支的更改后,你可能不再需要该分支了。如果你想删除分支,可以使用 -d 选项。下面的命令包含 -d 选项,告诉 git 删掉给出的分支(这里是"sidebar"分支)。

    高效分支

      为开始后面实验,执行以下操作

      1) 删除 前面建好的 siderbar 分支。

      2)所有文件暂存并提交到仓库

      3)切换到master分支

      4)运行git status, 确认出现  working tree clean 或 working directory clean

    分支实战

    现在,所有代码都位于 master 分支(默认分支)上。我们通过以下操作利用分支进行工作:

    • 向分支中添加内容

    • 创建新的分支

    • 在分支之间切换

    让我们使用分支完成以下更改:

    1. 在 master 分支上 - 向页面添加默认颜色

    2. 创建一个 sidebar 分支 - 为页面创建侧栏

    3. 在 master 分支上 - 更改页面的标题

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

    5. 创建一个 footer 分支 - 向脚注中添加社交链接

    更改 1 - 添加页面颜色

    确保位于 master 分支上,并向 css/app.css 添加以下内容:

    body {
        background-color: #00cae4;
    }
    保存文件,然后将该文件添加到暂存区,并将其 commit 到仓库。
    commit 的内容可写: Set background color for page
    
    通过git log 检查commit 记录

    更改 2 - 添加侧栏

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

       git branch sidebar  840b8de

      

    通过向 HTML 文件添加以下 <aside> 代码(红色部分),该代码将为页面添加一个侧栏:

    <div class="container">
        <main>
        </main>
    </div>
    
    
    <footer>
        Made with ♥ @ Udacity
    </footer>

    更改 3 - 更改 master 上的标题

    切换到 master 分支并更新页面标题。

    使用 git checkout 命令切换到 master 分支。(注意,新的侧栏的 HTML 不在了!因为所有代码都妥善地保存在 sidebar 分支上。)

    现在将页面的 <h1> 标题从"Expedition"改为吸引人的"Adventure"?

    现在该保存 index.html 文件并进行 commit 以将此更改添加到仓库中。( commit 消息"Improve site heading for SEO"),记住提交后用git log --oneline 检查。

    同时查看所有分支

        我们已经做出了所有需要做出的更改!很棒!

    我们已经在三个不同的分支上进行了多项更改。我们在 git log 输出结果中看不到其他分支,触发切换到某个分支。如果能在 git log 输出结果中看到所有分支,是不是很棒?

    你到现在为止已经知道,git log 命令非常强大,可以显示此信息。我们将使用新的 --graph 和 --all 选项:

    $ git log --oneline  --graph --all

    --graph 选项将条目和行添加到输出的最左侧。显示了实际的分支。--all 选项会显示仓库中的所有分支。

    运行此命令将显示仓库中的所有分支和 commit:

    更改小结

    我们做出了以下更改:

    1. 我们在 master 分支上向页面添加了默认颜色

    2. 我们创建了 sidebar 分支并为侧栏添加了代码

    3. 我们在 master 分支上更改了页面的标题

    4. 我们在 sidebar 分支上向侧栏添加了更多内容

    5. 我们创建了 footer 分支并向脚注中添加了社交链接

    这些更改都发生在不同的分支上。让我们用 git 合并所有这些更改吧。将分支组合到一起称为合并(merge)。

    合并

           主题分支(例如 sidebar)的作用是让你做出不影响 master 分支的更改。当你在主题分支上做出更改后,如果觉得不想要该分支上的更改,则可以删掉该分支,或者你决定要保留更改,则可以将该分支上的更改与其他分支上的更改合并。

    将分支组合到一起称为合并。

    git 可以自动将不同分支上的更改合并到一起。这种分支和合并功能正是 git 的强大之处!你可以在分支上做出小的或大的更改,然后使用 git 合并这些更改。

    发生合并时,git 将:

    • 查看将合并的分支

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

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

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

     

    合并指令

    git merge 指令用来合并 git 分支:

    要合并 sidebar 分支,确保你位于 master 分支上,并运行:

    $ git merge sidebar




    合并小结

    总结下,git merge 命令用来在 git 中合并分支:

    $ git merge <other-branch>

    合并有以下两种类型:

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

    • 普通类型的合并

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

      • 创建一个合并 commit

    
    

    合并冲突

    大部分情况下,git 将能够成功地合并分支。但是,有时候 git 无法完全自动地进行合并。合并失败时,就称为合并冲突。

    解决合并冲突

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

    1. 选择保留哪些行

    2. 删掉所有带指示符的行

    更改最后一个 commit

    你已经使用 git commit 命令提交了大量的 commit。现在,借助 --amend 选项,你可以更改最近的 commit。

    $ git commit --amend

    如果你的工作目录没有内容(也就是仓库中没有任何未 commit 的更改),那么运行 git commit --amend 将使你能够重新提供 commit 消息。代码编辑器将打开,并显示原始 commit 消息。只需纠正拼错的单词或重新表述即可!然后保存文件并关闭编辑器,以便采用新的 commit 消息。

    还原 commit

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

         假设 commit A 添加了一个字符,如果 git 还原 commit A,那么 git 将创建一个新的 commit,并删掉该字符。如果删掉了一个字符,那么还原该 commit 将把该内容添加回来!

      总结下,git revert 命令用于还原之前创建的 commit:

      $ git revert <SHA-of-commit-to-revert>

      此命令:

      将撤消目标 commit 所做出的更改

    创建一个新的 commit 来记录这一更改

    重置

    初看,重置(reset) 似乎和 还原(revert) 相似,但它们实际上差别很大。还原会创建一个新的 commit,并还原或撤消之前的 commit。但是重置会清除 commit!

    实验总结与体会:

      通过这个实验,我们把GIT相关的基本操作完整的学习了一遍,虽然这种验证性的实验没有太大的操作难度,但确实相当的耗费精力,但是收入与支出成正比,这次实验所学到的操作方式,对我们后续的实验意义非凡。

    思考题:

      Q:总结分布式版本控制系统的核心机理

    在分布式版本控制系统是把代码仓库完整地镜像下来。有效避免了主机出错导致文件损坏的情况。每个用户都是独立的,虽然存在一个类似于中央服务器的主机给各个用户提供镜像文件,但是这个中央服务器在提供文件后,便对于用户再无影响,即使后续该主机报废,接收过镜像文件的主机依然可以正常工作

    
    
    
  • 相关阅读:
    自定义转化
    asp.net JSON(一)
    做一个会偷懒的码农
    活动和监视器
    linq 分组求和
    sql语句查询列的说明
    chartControl
    LayOutControl
    sql 给表结构增加说明
    我的单件模式
  • 原文地址:https://www.cnblogs.com/KSMS123/p/12397099.html
Copyright © 2011-2022 走看看