软工实践专题——团队源代码管理

软工实践专题——团队源代码管理

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

答:我们的源代码控制在Github上,使用与之相匹配的Git系统。

 

(2) 一个代码文件被签出之后,另一个人可以签出这个文件,并修改么?

a) 有几种设计,各有什么优缺点?

答:有两种设计:

①签出文件后,此文件就加锁,别人无法签出。

②所有人都可以自由签出文件。

    优缺点是:由于现阶段的开发规模比较小,于是为了最大化效率,我们没有对文件迁入迁出进行过多的限制。将文件在迁入迁出时加锁,显然可以保证源代码修改的同步性,减少不必要的冲突和错误,但是这样的缺点是显而易见的,由于缺乏了并行性,项目开发的效率就被极大地降低了,极端情况下很有可能因为一个人的失误,导致全队项目的搁浅。反之,我们采用自由迁入迁出的方式,则与前者的优缺点互反了。

 

扫描二维码关注公众号,回复: 6293501 查看本文章

(3) 如何看到这个文件和之前版本的差异?

答:①在git管理中, 使用git diff即可看到文件和之前版本的差异。
git diff:是查看working tree(工作目录)与index file(暂存区)的差别的
git diff --cached:是查看index file(暂存区)与commit(本地仓库)的差别的。
git diff HEAD:是查看working tree(工作目录)和commit(本地仓库)的差别的。
在git里,这三个概念是很重要的,其中 git add的一个功能是将修改从工作目录添加到index file,commit的工能就是从index file的修改添加到 commit。
查看两个提交版本id的修改记录差异

$ git diff commit-id1 commit-id2

 

查看两个提交版本id修改了那些文件,可以使用

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

 

 

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

$ git log --name-only

 

 

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

 

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

答:我们使用Git来帮助我们完成了这件事。在一般情况下,git pull后git会自动合并Git修改的部分,自动的Merge。但是,也存在无法自动合并的情况:比如远程数据库和本地数据库的同一个地方都发生了修改的情况下,因为Git无法自动判断要选用哪一个修改,所以就会发生冲突。但是,Git会在发生冲突的地方打个标记!这时候我们需要通过一双慧眼来识别哪些都可以保留,哪些保留远程数据库的内容,哪些保留本地数据库的内容。在将文件冲突的内容合并后,删除掉<<<<< 和=====,>>>>>这样的东西,重新add,commit,push,即完成了一次手工合并。不过因为大家都是新手入门,不太会合理地人工合并冲突,所以项目经理本身在分配任务时,遵循了一个原则:尽量不让两个人的任务在同一个文件上产生重叠。每个人修改的文件范围或者其他都是固定的,一般不会存在两个人同时修改同样的文件。当然,前端和后端在修改时大部分时候都会产生冲突,这时候我们就使用了另一套机制来帮我们实现这一点:新建分支与分支合并。

 

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

场景: L一个一个地签入20个文件。在签入完10 个 .h 文件之后,他发现一些 .cpp 文件和最新的版本有冲突,他正苦恼如何合并。而此时ANN从客户端同步了所有最新代码,但是编译不成功 。因为有不同步的.h 文件和.cpp 文件!因此,其他组员也开始抱怨这件事

答:git本身就可保证在签入时的原子性,所以在项目开发流程中,我们没有遇到部分修改可以上传而某些部分的修改不能上传的混乱状态。

 

 

 

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

答:

在本地新建一个分支,再在新的分支上修复BUG。当前分支的内容就被保存在原来的位置上

 

 

(7) 如何给你的源代码建立分支?

场景:团队中有多个人再开发一个项目,另一人在开发一个新的功能,需要一周时间完成,他写了其中的30%还没有写完,如果他提交了这个版本,那么团队中的其它人就不能继续开发了。但是等到他全部写完再全部提交,大家又看不到他的开发进度,也不能继续干活,这如何是好呢? 

对于这个问题,我们就可以用分支管理的办法来解决,开发新功能时可以创建一个属于他自己的分支,其它人暂时看不到,他在自己的分支上全部开发完成时,再一次性的合并到开发分支上,这样我们既可知道他的开发进度,又不影响大家干活,是不是很方便呢? 

这里讲解Git的分支功能

创建分支:

我们进入到以前的项目里:

git branch

 

 

你会看到我们当前所出的分支为master。

git branch #查看当前分支状态

git branch BobBranch #创建名为BobBranch的分支

git checkout BobBranch #切换到BobBranch分支

 

git checkout -b test2 # 如果我们使用checkout -b 可以直接创建并切换到分支

 

 

删除分支

git branch -D test2 #如果处于该分支,会出现删除错误

 

 

分支提交

我先删除一个文件

 

 

正常add 和commit

 

git add .

git commit -m "Branch delete file and commit test"

创建一个分支提交的别名Bob,通过branch分支提交

git remote add Bob https://github.com/WytheO/gitTest.git

git push -u Bob BobBranch

 

 

那么结果是这样,因为你在配置git信息的时候,用户名邮箱没有更换,那么分支状态会显示你最新的提交且所处于哪个开发中的分支:

 

合并分支

当你回到你的主分支时,你会发现有个提示你的代码更新了,被谁谁分支。

 

 

主分支合并其他分支

git merge BobBranch #参数就是分支名

git status #查看发现commit有个分支信息的提交

 

 

主分支接收合并更新主分支

git push -u Wythe master #直接正常push,将BobBranch的提交push到主分支

可以看到主分支的test.txt也被删除了。

 

 

PS:git 创建开发分支,并合并代码

1、更新代码并创建新分支

git pull -r

git checkout -b dev

2、开发,并在本地提交改动

git add -A .

git commit -m "some words"

3、返回master 更新代码

git checkout master

git pull -r

4、进入dev分支更新代码

git checkout dev 

git rebase master

如果有冲突在开发分支下修改

5、合并分支并提交代码

git merge dev

git pull -r

git push

 

(8) 一个源文件,如何知道它的每一行都是什么时候签入的?

场景: 在开发过程中发现某一行代码出现问题而又不敢贸然改动, 这行代码是什么时候,为了什么目的,经过谁签入的呢?  直接修改的话会不会导致其他问题呢?  怎么办?

以Github为例:

如果你要查看文件的每个部分是谁修改的,那么 git blame 就可以做到. 只要运行git blame [filename],你就会得到整个文件的每一行的详细修改信息:包括SHA串,日期和作者。

 

 

也可以用"-L"参数在命令(blame)中指定开始和结束行:

$>git blame -L 160,+10 sha1_file.c

ace1534d (alsenlululu 2019-05-25 23:56:02 -0700      102)}

ace1534d (alsenlululu 2019-05-25 23:58:34 -0700       103)

0fcfd160 (Ann 2019-05-24 13:26:55 -0700       104)/*

 

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

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

 

 

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

 

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

  • (自动同步所有文件,自动构建,自动运行单元测试,碰到错误能自动发邮件给团队)

答:我们团队并没有构建自动测试脚本。

猜你喜欢

转载自www.cnblogs.com/Ann201/p/10937989.html