团队做业-WEEK 14- 团队源代码管理

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

 答：咱们团队的源代码控制在Git，Git是一款开源的分布式版本控制工具。用的是Win10系统。

 

(2)  一个代码文件被签出以后，另外一我的能够签出这个文件，并修改么？有几种设计，各有什么优缺点？

答：签出文件后主要有两种设计：

① 此文件被加锁，其余人没法签出

优势：能够保证每一个人获取的文件版本是最新的，也不会产生修改冲突。

缺点：这种方式花费的时间相对要长一些，由于其余人须要要等到其余人修改完文件后才能签出来进行本身的修改。

② 不加锁，全部人能够自由签出文件并进行修改

优势：你们能够各自修改本身须要修改的模块。

缺点：合并代码的时候，会产生冲突，须要人工去修改。特别是几我的修改一个文件涉及到相同函数的修改。

 

(3) 如何看到这个文件和以前版本的差别？

答：有如下方法看到这个文件和以前版本的差别：

① 查看两个提交版本id的修改记录差别

使用$ git diff commit-id1   commit-id2

 

② 查看两个提交版本id修改了那些文件

使用$ git diff commit-id1 commit-id2 --stat

 

③ 提交日志显示每一个版本的提交主题和具体修改的文件名字

使用$ git log --name-only

 

(4) 若是某个文件在你签出以后已经被别人修改，那么你如何合并不一样的修改（merge)?

答：在Git中，会对有冲突的代码作出相应的提示(conflict)，届时进行手动合并就能够合并不一样的修改了。

在Github中，能够经过git log命令来查看历史提交记录后进行合并不一样的修改。

 

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

答：能够经过git中的commit先将全部本地修改保存到本地版本库中，再统一push到服务器版本库中，这样就保证了修改的原子性。

 

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

答：首先备份在本地一份工程，而后在本地新建一个分支，在新的分支上进行bug的修复，当前分支的内容就被保存在原地。

 

(7) 如何给你的源代码创建分支？

答：在Github中：① 打分支：有条件地合并分支和主分支

② 新建一个分支，在这个分支上，回滚到用户所用的版本

 

在Git中：经过git reset --hard + 哈希值：回溯到指定版本

 

(8) 一个源文件，如何知道它的每一行都是何时签入的？

以Github为例：执行git blame命令，便可显示每一行都是何时签入的，为了什么目的签入的，签入人是谁。

或者在Github页面上：

 

(9) 如何给一个系统的全部源文件都打上标签，这样别人能够同步全部有这个标签的文件版本？

答：① 在Git上能够使用打基线（针对项目源码）的方式，打基线是将每次发布的版本源码放到一个文件夹下面，例：此次发布的是1.1版本，就在版本管理库(Git)里面的目录(tag)下，创建一个名字V1.1的分支，而后把V1.1版本的源码都放进去。但这样作的方式维护起来比较麻烦，V1.1发布之后，若是要改一些临时修复的紧急bug，还要在tag下的V1.1文件夹中创建一个patch文件夹来放修改bug涉及的源码文件。

② 在Github上发布的时候，能够编辑想要release的文件信息，建立标签并设置版本号并上传文件。这样的话，看提交历史就能够很清楚的找到LKG版本，并且也容易回滚。

 

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

• （自动同步全部文件，自动构建，自动运行单元测试，碰到错误能自动发邮件给团队）

答：鉴于水平有限，在部署自动构建的任务尝试不成功后，咱们团队决定进行手动测试，更新修改源代码后会自动更新备份，单元测试及其余测试也会在更新修改源代码后手动进行，有错误会在测试代码中修改，而后也会更新时间线上传修改过的代码，所以没有部署自动构建的任务。

 

团队总结：咱们在一点点深刻学习和探索Github和Git代码管理平台的过程当中，遇到了一些困难和问题，并花费了很多的时间去解决问题（有问题因水平问题暂没法解决），这让咱们发现咱们只是接触了Github和Git代码管理平台的皮毛，仍需继续努力学习Github和Git代码管理平台。