标签：本地 zhang 红色 测试 它的 png 兴趣 功能 web
(1) 你的团队的源代码控制在哪里？用的是什么系统？
答：我们的源代码控制在Github上，使用与之相匹配的Git系统。
(2) 一个代码文件被签出之后，另一个人可以签出这个文件，并修改么？
a) 有几种设计，各有什么优缺点？
答：有两种设计：①签出文件后，此文件就加锁，别人无法签出。②所有人都可以自由签出文件。
优缺点是：由于现阶段的开发规模比较小，于是为了最大化效率，我们没有对文件迁入迁出进行过多的限制。将文件在迁入迁出时加锁，显然可以保证源代码修改的同步性，减少不必要的冲突和错误，但是这样的缺点是显而易见的，由于缺乏了并行性，项目开发的效率就被极大地降低了，极端情况下很有可能因为一个人的失误，导致全队项目的搁浅。反之，我们采用自由迁入迁出的方式，则与前者的优缺点互反了。
(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会在发生冲突的地方打个标记！比如这样式的：
<<<<<<< HEAD
test in Local
=======
test in Remote
>>>>>>> 17c805…(Commit的Hash值)
==分割线上方是本地数据库的内容
==分割线下方是远程数据库的某次产生冲突的commit所修改的内容。这时候我们需要通过一双慧眼来识别哪些都可以保留，哪些保留远程数据库的内容，哪些保留本地数据库的内容。在将文件冲突的内容合并后，删除掉<<<<< 和=====，>>>>>这样的东西，重新add，commit，push，即完成了一次手工合并。不过因为大家都是新手入门，不太会合理地人工合并冲突，所以项目经理本身在分配任务时，遵循了一个原则：尽量不让两个人的任务在同一个文件上产生重叠。每个人修改的文件范围或者其他都是固定的，一般不会存在两个人同时修改同样的文件。当然，前端和后端在修改时大部分时候都会产生冲突，这时候我们就使用了另一套机制来帮我们实现这一点：新建分支与分支合并。
(5) 你有20个文件都是关于同一个功能的修改，你要如何保证这些文件都同时签入成功（修改的原子性）
答：Branch的出现，可以让任何一位开发者基于其他人的代码或环境都完整可用（即stable版）的环境下进行自己的部分的独立开发 。最后的合并工作可以放在一天之内，将所有的Branch上的feature合并到一个dev分支上来。但是这样面临的风险也是有的，多个分支同时合并时如果出现了比较大的冲突，合并起来必须小心翼翼。同时，在解决一个Issue的时候，也可以新建一个Issue分支，在解决了Issue后，可以使用分支合并的技术将两个或多个分支合并。
(6) 你的PC 上有关于三个bug 的修改， 但是都没有完成，这时你要紧急修改第四个bug，如何把本地修改放一边，保证在干净的环境中修改第四个bug, 并签入修改？
答：在Git里，不能完整地保证commit后整个环境处于可编译或可运行状态下的commit是不好的提交。所以在文件半完工的状态下，我们不可以使用commit来将文件修改的内容留下来。Git为我们提供了一种类似于操作系统里的保存现场的指令，那就是stash。 它可以把当前工作现场"储藏"起来，等以后恢复现场后继续工作，使用方法类似下面：
$ git stash
Saved working directory and index state WIP on master: 5655bdc Merge branch ‘mas
ter‘ of https://github.com/buaase/Phylab-Web
HEAD is now at 5655bdc Merge branch ‘master‘ of https://github.com/buaase/Phylab
-Web
这时候就会发现，add了以后的东西都被"雪藏"起来，现在的工作区非常干净，我们这时候可以在一个干净的环境中修复紧急的bug并提交，签入，在push后，再使用git stash apply 或者 git stash pop来将保存起来的内容取出来继续开开心心地开发啦。
(7) 如何给你的源代码建立分支？
答： 直接点击 Branch，然后在弹出的文本框中添加自己的 Branch Name 例如code-edits然后点击蓝色的Create branch就可以了，这样一来，你这个项目就有2个分支了（master 和 code-edits），下面显示了创建过程以及创建后而界面：
*由上面的分支合并的流程图可以发现，1 个库可以有多个分支并行的进行开发，但是最后只有 1 个会被 merge 进来，因此当某一个分支被合并到进 master 分支后，其他的并行分支的提交都会被是作为冲突 conflict，解决这个冲突的唯一办法就是，每次做修改之前，记得更新版本库，使自己的分支与 master 分支保持一致。
具体操作步骤如下：
1、Git init （在本地工程目录下），生成.git 文件夹
2、上传修改的文件
(*可替换成具体要上传的文件名，*表示提交所有有变化的文件)
3、添加上传文件的描述
（” code-edits “为分支名）
4、（创建分支）
git branch code-edits
5、（切换分支）
git checkout code-edits
6、与远程分支相关联
git remote add origin https://github.com/xingpengzhang/lcb.git
（” lcb “ 为工程名）
7、（将分支上传）
git push origin code-edits
*我们这里出现了一点问题但是低下也给出了一些可能的原因，以及寻求解决办法的方式，这里我们就不再详细介绍了，感兴趣的同学可以根据提示自己去连接一下。
下面是.git文件中新增的一些信息，有关分支的详细信息都可以在里面找到：
(8) 一个源文件，如何知道它的每一行都是什么时候签入的？
答：针对一个源文件的每一行是在什么时候签入，在github里有非常好的支持，如下图：
在上图中我们可以看到，这个安卓程序在5次提交中被修改了，分别是在上图所示commit中被修改过，但是可惜的是没有带有比较清晰的commit日志，无法知道它是为何被签入，修改又是为了什么。以及所有跟它有关的所有commit提交信息。所以在这里要特别提醒：一个良好的团队应当维护一个良好的commit日志，并且有所规范，但是我们组在这一点上还非常欠缺...
(9) 如何给一个系统的所有源文件都打上标签，这样别人可以同步所有有这个标签的文件版本？
答：使用git来打标签这件事，在Github中是可以很方便来做这件事。
每次发布到一定成果后，就需要发布一个realease版本，但是这样的话，是对commit本身打标签。在git里，标签分为两种类型：轻量标签和附注标签。轻量标签是指向提交对象的引用，附注标签则是仓库中的一个独立对象。
想查看tag的话，可以使用git tag来查看，如下：
如果想回到某个标签时某个文件的状态，那么只要使用git checkout tag(标签名) 即可，如下面这个gif所示：
(10) 你的团队是否能部署自动构建的任务
决意采用了drone.io来进行自动化的单元测试，每次测试都会自动按照预定的脚本运行单元测试，单元测试通过以后可以在Github的ReadMe里体现出来。
是这样的标志：
点开build passing的示例，我们可以看到在drone.io中我们部署的自动化测试：
每一次commit都会触发自动化测试，在部署成功后（只针对master分支），已经test了38次。
在Setting中也可以看到，我们在build出错时，会自动通知我的邮箱（qianlxc@126.com)
标签：本地 zhang 红色 测试 它的 png 兴趣 功能 web
原文地址：https://www.cnblogs.com/blackDuck/p/10928344.html
