软件工程 实验一 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.1 安装git

安装git成功。

 

1.2 配置git

1.2.1 配置git用户名、邮箱等

 配置git,设置Git 用户名、Git 邮箱、Git 输出内容带有颜色标记等。

 

1.2.2 配置git与编辑器结合

 将git与本机上的sublime text 3结合使用。

 

1.3 创建仓库

1.3.1 创建仓库目录

创建目录se2020-git-course,在该目录中,创建另一个目录new-git-project,使用 cd 命令移到 new-git-project 目录下。

 

1.3.2 创建空仓库

 使用git init命令,在当前目录下初始化生成一个空的 Git 仓库。

 

在克隆仓库之前,首先应确定此时的目录位置,其次这个目录下没有存在的仓库((可在目录下运行 git status ,查看目录里的文件是否在git仓库,此外如果你位于 Git 仓库目录下,提示符将包含一个用小括号括起来的名称,注意上图新建仓库的 master),然后使用git clone命令。

 

1.3.3 克隆仓库

出现错误,因为线路问题无法克隆完整,更换网络使用手机热点后解决问题。

 

在相应文件夹下出现了克隆成功的文件。

 

1.3.4 克隆仓库的状态

 先cd到course-git-blog-project目录,再使用git status命令查看情况。

 

1.4 查看仓库内容

1.4.1 使用git log命令

 使用git log命令,显示如图。其特点是:git log 命令用于显示仓库中所有 commit 的信息

默认情况下,该命令会显示仓库中每个 commit 的:

  • SHA

  • 作者

  • 日期

  • 消息

 

1.4.2 使用git log --oneline命令

 使用git log --oneline命令,显示如图,使输出结果更简短,并节省大量空间。其特点是:

  • 每行显示一个 commit

  • 显示 commit 的 SHA 的前 7 个字符

  • 显示 commit 的消息

 

1.4.3 使用git log --stat命令

 使用git log --stat命令,该命令用来显示 commit 中更改的文件以及添加或删除的行数。其特点是:

  • 显示被修改的文件

  • 显示添加/删除的行数

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

 

 1.4.4 使用git log -p命令

 使用git log -p命令,显示如图,该命令可用来显示对文件作出的实际更改。其特点是:

  • 此命令会向默认输出中添加以下信息:

  • 显示被修改的文件

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

  • 显示做出的实际更改

 

1.4.5 使用git show命令

 git show 命令将仅显示一个commit,

git show 命令的输出和 git log -p 命令的完全一样。因此默认情况下,git show 会显示:commit、作者、日期、commit 消息、补丁信息。

 

1.5 创建文件,提交commit

1.5.1 创建文件,将文件转入缓存区

 在new-git-project目录下创建index.html文件、css文件夹与js文件夹,cd到new-git-project使用git status命令,可知新创建的这些文件git未跟踪这些文件,需要将这些文件放入暂存区。

 

 使用git add命令将文件放入暂存区,该命令使用后无任何提示,再使用git status命令,可看到要放入暂存区的文件已成功放入。

 

 使用git add .命令可使当前目录的所有文件和目录都转入暂存区,使用git status命令可看到多转入了一个文件,原因是我的new-git-project目录下还有course-git-blog-project文件夹,可使用git rm --cached命令撤销该文件的转入。

 

 

 使用git rm --cached命令撤销course-git-blog-project文件失败,提示我使用-f命令来撤销,最终完成course-git-blog-project文件的撤销。

 

1.5.2 提交commit

 使用git commit命令提交commit,提示我配置git,可是我之前已经配置过了,我只好接着这条语句后面配置git。

 

 成功打开编辑器

 

 在打开的文件中第一行添加文本“Initial commit”,再关闭编辑器,终端出现以上内容代表提交commit成功。

 

1.5.3 更改文件,重新提交commit,并添加提交说明

 更改index.html文件的内容,再在终端使用git status命令,显示如上图,表示文件被更改。

 

提交commit,使用-m添加提交说明。

 

1.5.4 git commit小结

git commit命令会取出暂存区的文件并保存到仓库中。

此命令将打开配置中指定的代码编辑器。

在代码编辑器中:

  • 必须提供提交的文字说明,记录或解释所做的修改

  • 以 # 开头的行是注释,将不会被记录

  • 添加提交说明后保存文件

  • 关闭编辑器以进行提交

然后使用 git log 检查你刚刚提交的 commit!

 

1.5.5 良好的提交说明

建议

  • 消息篇幅简短(少于 60 个字符)

  • 解释提交的作用(不是如何更改或为何更改!)

禁忌

  • 请勿解释为何做出了这些更改

  • 请勿解释如何进行了更改(这是 git log -p 的目的!)

  • 请勿使用单词"and"

  • 如果你必须使用 "and",则你的提交说明可能进行了太多的更改,将这些更改拆分为独立的 commit

  • 例如 "make the background color pink and increase the size of the sidebar"

解释原因

如果你需要解释为何进行了提交,也可以!

    在编写提交说明时,第一行是消息本身。消息之后空一行,然后输入正文或说明,包括关于为何需要该 commit 的原因详情(例如 URL 链接)。提交说明的详情描述部分包含在 git log 中

如果你属于某个团队,他们可能已经制定了提交说明编写方式。

 

1.6 标签、分支

1.6.1 使用git tag命令添加注释标签

 使用git tag -a命令为文件创建一个带注释的标签,并在打开的编辑器中第一行输入注释内容。

 

 

 使用git tag命令,显示注释的内容。

 

1.6.2 使用git tag -d命令删除标签

 

 

 如果注释内容输入错误或需要修改,可使用git tad -d命令删除标签。

 

1.6.3 git tag 小结

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

此命令将:

  • 向最近的 commit 添加标签

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

 

1.6.4 分支,git branch与git checkout命令

 使用git branch命令,可查看当前活跃分支,即HEAD指向的分支。使用git branch后跟名字,可创建一个分支,再使用git checkout命令可使当前活跃分支转变为所命名的分支。

 

1.6.5 删除分支

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

1)如果某个分支上有任何其他分支上都没有包含的 commit(也就是这个 commit 是要被删除的分支独有的),git 不会删除该分支。

2)如果创建了 sidebar 分支,向其添加了 commit,然后尝试使用 git branch -d sidebar 删除该分支,git 不会删除该分支,因为无法删除当前所在的分支。

3)如果切换到 master 分支并尝试删除 sidebar 分支,git 也不会删除,因为 sidebar 分支上的新 commit 会丢失!要强制删除,需要使用大写的 D 选项   git branch -D sidebar

 

1.6.6 git branch 小结

总结下,git branch 命令用来管理 git 中的分支:

# 列出所有分支
$ git branch
# 创建新的"footer-fix"分支
$ git branch footer-fix
# 删除"footer-fix"分支
$ git branch -d footer-fix

此命令用来:

  • 列出本地分支

  • 创建新的分支

  • 删除分支

 

1.6.7 分支实战

在 master 分支上向页面添加默认颜色,创建一个 sidebar分支,为页面创建侧栏,在 master 分支上更改页面的标题,使用git log --oneline -grapg --all命令同时查看所有分支。具体操作如上图。

 

1.7 合并

1.7.1 使用git merge命令合并两个分支

 

 

 确保现在在master分支上,合并sidebar分支需要使用git merge命令,弹出编辑器已有默认的注释,直接关闭编辑器,终端出现上述内容。

 

1.7.2 合并小结

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

$ git merge <other-branch>

合并有以下两种类型:

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

  • 普通类型的合并

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

    • 创建一个合并 commit

 

1.7.3 合并冲突

 制造合并冲突,在当前分支master下更改index.html的标题并提交commit,同时在提交commit后的前面创建新分支(更改标题前所在的SHA),更改标题为不同的内容,再提交commit,最后在master分支下合并刚才创建的分支,出现冲突,打开修改的文件,删除注释,留下想要的内容并保存,最后提交commit,出现以上内容。

 

1.7.4 合并冲突小结

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

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

  • 决定保留哪些行

  • 保存文件

  • 暂存文件

  • 提交 commit

注意一个文件可能在多个部分存在合并冲突,因此检查整个文件中的合并冲突指示符,搜索 <<< 能够帮助找到所有这些指示符。

 

1.8 撤销更改

1.8.1 使用git reset命令重置(清除)commit

 

 

 在当前分支创建备用分支backup,然后重置HEAD父元素,使用git status命令可看到重置成功。若想回到原来状态,使用git checkout -- index.html命令,把index.html文件在工作区的修改全部撤销,再使用git merge backup命令即可回到原来状态。

 

1.8.2 git reset 小结

总结下,git reset 命令被用来清除 commit:

$ git reset <reference-to-commit>

它可以用来:

  • 将 HEAD 和当前分支指针移到引用的 commit

  • 使用 --hard 选项清除 commit

  • 使用 --soft 选项将 commit 的更改移至暂存区

  • 使用 --mixed 选项取消暂存已被 commit 的更改

我们通常会用到祖先引用来指代之前的 commit。祖先引用包含:

  • ^ 表示父 commit

  • ~ 表示第一个父 commit

 

1.8.3 commit引用

你已经知道可以使用 SHA、标签、分支和特殊的 HEAD 指针引用 commit。有时候这些并不足够,你可能需要引用相对于另一个 commit 的 commit。例如,有时候你需要告诉 git 调用当前 commit 的前一个 commit,或者是前两个 commit。我们可以使用特殊的“祖先引用”字符来告诉 git 这些相对引用。这些字符为:

  • 父 commit : 以下内容表示当前 commit 的父 commit
    • HEAD^
    • HEAD~
    • HEAD~1
  • 祖父 commit – 以下内容表示当前 commit 的祖父 commit
    • HEAD^^
    • HEAD~2
  • 依次类推

git reset根据所使用选项来判断是清除、暂存之前 commit 的更改,还是取消暂存之前 commit 的更改。这些选项包括:

  • 使用 --hard 选项清除 commit
  • 使用 --soft 选项将 commit 的更改移至暂存区
  • 使用 --mixed 选项取消暂存已被 commit 的更改(默认)

 

实验总结与体会

  本次实验对于我们初次使用git的学生来说,非常新颖非常有趣,在此之前从未了解过有关版本管理的知识,通过这次实验让我明白了版本管理的重要性。软件是迭代更新的,需要有强大的软件来管理版本更新,通过git的有关操作使我对于版本管理的有关内容有了更深层次的了解。此次实验因为特殊情况,不能在学校开展,是新学期的第一个实验,也是第一次在家做实验,再加上此次试验的趣味性,使我收获颇多。

思考题

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

  分布式的版本控制就是每个人都可以创建一个独立的代码仓库用于管理,各种版本控制的操作都可以在本地完成。每个人修改的代码都可以推送合并到另外一个代码仓库中。分布式版本控制系统DVCS。在这类系统中像Git,Mercurial,Bazaar以及Darcs等,客户端并不只提取最新版本的文件快照,而是把原始的代码仓库完整地镜像下来。这么一来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的提取操作,实际上都是一次对代码仓库的完整备份。这类系统指定和若干不同的远端代码仓库进行交互。在同一个项目中分别和不同工作小组的人相互协作。根据需要设定不同的协作流程,比如层次模型式的工作流,而这在以前的集中式系统中是无法实现的。

posted @ 2020-02-27 17:05  motion丶  阅读(359)  评论(0)    收藏  举报