软件工程综合实践专题——第四次团队作业

 

 

 

1.你的团队的源代码控制在哪里？用的是什么系统？

　　答：我们会把所有的代码都会上传一份最新的版本到GitHub上，在windows10系统上操作。

2.一个代码文件被签出之后，另一个人可以签出这个文件，并修改么？有几种设计，各有什么优缺点？

　　答：有两种设计：①签出文件后，此文件就加锁，别人无法签出。②所有人都可以自由签出文件。一个代码文件被签出，另外一个人可以迁出这个文件并修改。

　　优缺点：为了最大化效率，我们没有对文件迁入迁出进行过多的限制。将文件在迁入迁出时加锁，显然可以保证源代码修改的同步性，减少不必要的冲突和错误，但是这样的缺点是显而易见的，由于缺乏了并行性，项目开发的效率就被极大地降低了，极端情况下很有可能因为一个人的失误，导致全队项目的搁浅。反之，我们采用自由迁入迁出的方式，则与前者的优缺点互反了。针对这两种设计，我们认为第一种可以保证项目代码版本控制更加合理，不会有类似读“脏数据”的情况出现，但是这样也会花费更多的时间，操作稍微会繁琐一些；相反第二种设计文件不加锁的时候，修改方便，适合我们现在这样刚起步的小项目，但是代码上会出现一定程度上的错乱。

3.如何看到这个文件和之前版本的差异？

　　答：使用git diff即可看到文件和之前版本的差异。

git diff：是查看working tree（工作目录）与index file（暂存区）的差别的

git diff --cached：是查看index file（暂存区）与commit（本地仓库）的差别的。

git diff HEAD：是查看working tree（工作目录）和commit（本地仓库）的差别的。

　　另外，在Github中，也可以通过可视化的界面来看到每次修改的代码（包括增加，删除）文件与修改的具体位置，修改的具体内容。可以看到每次修改的文件路径、文件的内容、红色代表删除掉的内容，绿色代表添加的内容。

4.如果某个文件在你签出之后已经被别人修改，那么你如何合并不同的修改（merge)?

　　答：使用git-merge命令将两个开发历史合并在一起。Git可以方便地对有简单不同的修改进行合并，但对于有逻辑冲突的部分将会给出conflict的提示，这时需要手工修改。针对文件的不同状态给出不同的颜色提示。使用分支，保持主分支的整洁。在分支进行提交，然后切到主分支更新(git pull —rebase)，再合并分支、推送。这样的流程会避免交叉合并的情况出现（不会出现共同祖先节点为多个的情况）。

但是，Git会在发生冲突的地方打个标记。比如这样式的：

　　<<<<<<< HEAD

　　test in Local

　　=======

　　test in Remote

　　>>>>>>> 17c805…(Commit的Hash值)

　　==分割线上方是本地数据库的内容

　　==分割线下方是远程数据库的某次产生冲突的commit所修改的内容。

　　这时候我们需要识别哪些都可以保留，哪些保留远程数据库的内容，哪些保留本地数据库的内容。在将文件冲突的内容合并后，删除掉<<<<< 和=====，>>>>>这样的东西，重新add，commit，push，即完成了一次手工合并。

这就需要我们在分配任务时遵循一个原则：尽量不让两个人的任务在同一个文件上产生重叠。每个人修改的文件范围或者其他都固定化，尽量不让两个人同时修改同样的文件。当然，像前端和后端在修改时大部分时候都会产生冲突，这时候我们就会使用另一套机制来帮我们避开这一点：新建分支与分支合并。一般情况下，git pull后git会自动合并Git修改的部分，自动的Merge。但是，也存在无法自动合并的情况：比如像远程数据库和本地数据库的同一个地方都发生了修改的情况，此时Git无法判断要选用哪一个修改，所以就会发生冲突。但是，Git会在发生冲突的地方打个标记！

5.你有20个文件都是关于同一个功能的修改，你要如何保证这些文件都同时签入成功（修改的原子性）

　　答： 在签入代码之前，本人应当现在本机上测试，测试通过，便可以很放心的将代码直接签入其中，如果测试不通过，就继续在本机上测试修改知道解决版本冲突问题。在Git中，所有在本地仓库中修改的文件都要统一经过commit为新的本地版本后，再push至远程分支。这保障了本地修改提交的原子性，同时git服务器远程提供的修改操作也具有原子性。这样就保障了整体修改的原子性。可以直接对工程文件进行整个的签入挂起的更改，或者在修改之前为将要修改的文件都上锁，防止在签入的时候进行签出操作。

6.你的PC 上有关于三个bug 的修改， 但是都没有完成，这时你要紧急修改第四个bug，如何把本地修改放一边，保证在干净的环境中修改第四个bug, 并签入修改？

　　答：使用branch解决任务切换问题。建一个自己的分支去修改和调试代码, 如果别人或者自己发现原有的分支上有个不得不修改的bug，我们往往会把完成一半的代码 commit提交到本地仓库，然后切换分支去修改bug，改好之后再切换回来。使用'git stash'就可以将你当前未提交到本地（和服务器）的代码推入到Git的栈中，这时候你的工作区间和上一次提交的内容是完全一样的，所以你可以放心的修 Bug，等到修完Bug，提交到服务器上后，再使用'git stash apply'将以前一半的工作应用回来。

git stash

Saved working directory and index state WIP on master: sxu Merge branch 'mas

ter' of https://github.com/siyux/buytickets

HEAD is now at 5655bdc Merge branch 'master' of https://github.com/siyux/buytickets

这时候就会发现，add了以后的东西都被"雪藏"起来，现在的工作区非常干净，我们这时候可以在一个干净的环境中修复紧急的bug并提交，签入，在push后，再使用git stash apply 或者 git stash pop来将保存起来的内容取出来继续开发。

7.如何给你的源代码建立分支？

　　答：直接点击 Branch，然后在弹出的文本框中添加自己的 Branch Name 例如sxu然后点击蓝色的Create branch就可以了，这样一来，你这个项目就有2个分支了（master 和sxu），下面显示了创建过程以及创建后而界面

 

分支是为了将修改记录的整体流程分叉保存。分叉后的分支不受其他分支的影响，所以在同一个数据库里可以同时进行多个修改。分叉的分支可以合并。在数据库进行最初的提交后, Git会创建一个名为master的分支。因此之后的提交，在切换分支之前都会添加到master分支里。在Git中可以自由地建立分支。但是，要先确定分支  的运用规则才可以有效地利用分支。

 还有一种是在Git命令管理分支，具体操作如下：

　　1）Git init （在本地工程目录下），生成.git 文件

 

　　2）git branch命令查看本地分支

 

　　3）用 git branch  sxu本地创建新分支

　　4）git checkout sxu 切换到新分支

　　5） git checkout -b aut

　　6）git push origin 将新分支推送到github

　　7）git branch -d sxu 删除本地分支，注意不能删除当前分支，要先切换再删除

8.  一个源文件，如何知道它的每一行都是什么时候签入的？

　　答：针对一个源文件的每一行是在什么时候签入，在github里有非常好的支持，如下图：

9.如何给一个系统的所有源文件都打上标签，这样别人可以同步所有有这个标签的文件版本？

　　答：使用git来打标签这件事，在Github中是可以很方便来做这件事。每次发布到一定成果后，就需要发布一个realease版本，但是这样的话，是对commit本身打标签。在git里，标签分为两种类型：轻量标签和附注标签。轻量标签是指向提交对象的引用，附注标签则是仓库中的一个独立对象。

想查看tag的话，可以使用git tag来查看，如下：

如果想回到某个标签时某个文件的状态，那么只要使用git checkout tag(标签名) 即可，如下面这个gif所示：

10.你的团队是否能部署自动构建的任务 

　　答：当我们提交代码到GitHub后，可以在Jenkins上执行构建，但是每次都要动手去执行略显麻烦，今天我们就来实战Jenkins的自动构建功能，每次提交代码到GitHub后，Jenkins会进行自动构建。

Jenkins是一个非常有名的CI工具，开源、免费，通过jenkins我们可以更加智能、快速的持续集成，尽早的发现代码里的问题并及时的部署上去。

首先先下载Jenkins,网址：https://jenkins.io/download/ 

 

运行压缩包中的msi文件，直接根据提示进行安装，安装好后，在浏览器上打开http://localhost:8080/,jenkins网址，获取并输入管理员密码，密码可在界面上的路径中获取，Jenkins默认无需登录即拥有所有权限，这肯定是极不安全的。这里简单的配置一下，让用户登录后才可以操作。

 

配置后的最终结果截图：

 

　　新建任务：在左侧栏选择新建，填上名称，选择构建一个自由风格的软件项目，点击保存，进入到配置页。这个页面涵盖了对这个任务的所有配置。

　　源码管理：选择Git, Repository URL里填上Github的地址，Credentials -> Add，填上Github的用户名密码。这个是Jenkins拉取源码时需要的凭证。 "Branches to build"填上分支名，表示Jenkins将拉取该分支的源码，后面触发器也只针对该分支。

　　构建触发器：表示在什么情况下构建项目，如果选择“Poll SCM”，然后在日程表里填上cron表达式，例如"H/5 * * * *"，表示每5分钟检查一次，有代码变更就构建项目。这里我们不选Poll SCM，而是用Gitub插件来做到实时构建。在“构建”配置里，选择“增加构建步骤”，选择“Execute shell”，即可填写你要执行的构建命令。对于Java项目，这里一般是Ant或Maven命令。对于我们项目，主要是执行shell命令。

构建后操作

构建后操作分两种情况：

• 构建成功后，将程序部署上去；

• 构建失败后，发送通知邮件。

但是无论是部署程序还是发送邮件，在“增加构建后操作”里都找不到对应的选项。所以还需要安装一些额外的插件。

按照上面所说的安装插件的方法，安装以下两个插件：

• Post build task

• PostBuildScript

这两个插件都是用来执行shell脚本的，不同的是Post build task插件可以根据不同的构建输出做不同的动作，当前面构建失败时，可以通过匹配失败的输出来执行发送邮件操作。

构建成功后自动部署

增加构建后操作步骤 -> Execute a set of scripts，在Command里填上部署脚本，并勾上Execute script only if build success。这样就实现了构建成功自动部署。完成以上配置后，就实现了项目的CI/CD。Jenkins非常灵活，以上步骤需要根据自己的实际情况做调整。