小组名称：飞天小女警
项目名称：礼物挑选小工具
小组成员：沈柏杉（组长）、程媛媛、杨钰宁、谭力铭
0.如果你的团队来了一个新队员，有一台全新的机器，你们是否有一个文档，只要设置了相应的权限，她就可以根据文档，从头开始搭建环境，
并成功地把最新、最稳定版本的软件编译出来，并运行必要的单元测试？（在这过程中，不需要和老队员做任何交流）
答：团队在初期编译了一篇文档，供组员或其他成员搭建环境，如果有需要可以向组长索取。
1.你的团队的源代码控制在哪里？用的是什么系统？如何处理文件的锁定问题？场景：程序员果冻正在对几个文件进行修改，实现一个大的功能， 这时候，程序员小飞也要改其中一个文件，快速修复一个问题。怎么办？一个代码文件被签出 (check out) 之后，另一个团队成员可以签出这个文件，并修改，然后签入么？有几种设计，各有什么优缺点？例如，签出文件后，此文件就加锁，别人无法签出；或者，所有人都可以自由签出文件
我们用git控制代码版本。
让个人根据自己的i情况处理，当其影响到整个团队时，就尽量严格，因为整个团队都可能会受影响，同时提高可预见性，公开显示固定的构建时间对于该问题中的场景描述，是否会造成损失要具体问题具体分析，有的时候宽一些更适宜，有的时候严一些比较没有损失，于是我们根据构建执法的宽严表来进行工作，当团队成员的行为只是影响到个人时，就尽量宽松，其实还是用电话沟通的，毕竟我们的项目很小。
| 步骤 | 宽 | 严 | 势 |
| 签出 | 自由签入 | 签出时，将文件上锁 | 很多人都要同时编译同一个文件 |
| 本地单元测试 | 不要求 | 要求 | 每个模块都要写单元测试 |
| 本地签入测试 | 不要求 | 要求 | BVT还没有完成 |
| 签入时间 | 任何时候 | 每天固定时间开放 | 目前签入情况很混乱 |
| 签入冲突处理 | 合并后即可签入 | 合并后，再重新编译测试提交 | 重新测试会花费比较多的时间 |
| 签入必须经过代码复审 | 随意 | 必须 | 开发人员 有一半时新员工必须通过代码复审建立良好规范 |
| 签入时必须运行代码分析工具 | 不要求 | 要求 | 代码分析工具尚未配置好 |
| 签入时单元测试必须同时签入 | 不要求 | 要求 | 每个模块要求写单元测试 |
| 签入时多个相关文件必须同时签入 | 不要求，可以签入单个文件 | 要求 | 保证每一个签入都不会导致构建失败 |
| 签入必须和一个工作项关联 | 不要求 | 要求 | 所有的工作都要保证与工作项跟踪 |
|
设定专用服务，自动处理提交的Shelveset.构建。BVT，然后签入代码 |
不要求 | 设置 | 需要很多人力来设计并维护 |
2.如何看到这个文件和之前版本的差异？ 如何看到代码修改和工作项 （work item），缺陷修复 （bug fix) 的关系。
场景1： 程序员果冻看到某个文件被修改了，他怎么看到这个文件在最近的修改究竟改了哪些地方？
场景2： 程序员果冻看到某个文件在最新版本被改动了100 多行， 那么和这100多行对应的其他修改在什么文件中呢？ 这个修
改是为了解决哪些问题而作的呢？ 那些问题有工作项 （work item，issue），或者bug 来跟踪么？
上述场景中遇到的问题可以通过如下操作进行解决。
到coding上项目的仓库，然后从版本中找到提交记录，点击提交记录就可以看到历史commit版本
找到想要查看的历史版本点击其对应的哈希值，进入该版本commit时所做的所有修改
一、切换到目录
首先切换到要查看的文件所在的目录：
cd packages/apps/Mms/src/com/android/mms/ui/
二、git log --pretty
然后使用下面的命令可列出文件的所有改动历史，注意，这里着眼于具体的一个文件，而不是git库，如果是库，那改动可多了去了～
git log --pretty=oneline 文件名
如：
root@ubuntu:android_src/packages/apps/Mms/src/com/android/mms/ui# git log --pretty=oneline MessageItem.java
27209385caf678abe878375a470f4edd67a2d806 fix to process force close when empty address contained in card
0e04b16f1dad7dc0a36e2235f7337bc656c365c7 display for 1970-1-1
e4abf3a213197491e0855e101117b59b5dc0160d HREF#13954 receive, store, and display wap push
356f6def9d3fb7f3b9032ff5aa4b9110d4cca87e HREF#16265_uim_show_time_error
350f9d34c35ab50bdb4b2d43fb3ff9780e6c73fa fix xxxx
715e32f97bd9d8ce4b5ba650b97ba4b137150456 Fix ANR from calling Contact.get()
fd8357ff5febab0141e1beb8dd3b26f70416b108 Fix missing From field
d130e2e6dc448fd80ecb70f0d31e3affb9888b9a fix bug 2112925: don't display zip file garbage content in MMS.
0e19f738c114f86d0d88825ee48966015fb48b6d Don't always show sent timestamp
52f854cbb75e8f9975c7e33216b828eb2f981095 Don't show Anonymous as the MMS sender
331864544ec51ba6807fc5471cc6d537b7fef198 add search capability
33a87f96f8c625aa10131a77a3968c97c4ec5a62 Remove all references to ContactInfoCache except those in Contact.
70c73e05a792832aa28da751cdaf3fa83a7b8113 Begin moving all conversation data behind a data model with a cache.
48da875f1beea835c6771977e5bd8a9aa3d4bc10 Begin adding UI unit tests to the Mms app.
66dde9460badebf8e740275cabde9cca256006eb Stop requiring a Context to be passed in to ContactInfoCache.
591d17e9a51bb9f829d6860dc7aa0bad25062cd5 auto import from //branches/cupcake_rel/...@138607
72735c62aba8fd2a9420a0f9f83d22543e3c164f auto import from //depot/cupcake/@135843
892f2c5bf965b1431ae107b602444a93f4aad4a3 auto import from //depot/cupcake/@135843
153ae99e0a7d626a24d61475eeb133249deb448c auto import from //depot/cupcake/@132589
abd7b2d90f7491075f1daba4b4cccdfc82f8ddd1 auto import from //depot/cupcake/@137055
59d72c57ce9c319b6cd43ce2ab36b7076c9e821f auto import from //branches/cupcake/...@132276
44cea74dc55e2459262d0d765ef4a69267dd09b0 auto import from //branches/cupcake/...@131421
0f236f55349f070ac94e12cca963847173393da8 Code drop from //branches/cupcake/...@124589
8eed706474910ccb978acda03e85d3261037da6e Initial Contribution
三、git show
如上所示，打印出来的就是针对文件MessageItem.java的所有的改动历史，每一行最前面的那一长串数字就是每次提交形成的哈希值，接下来使用git show即可显示具体的某次的改动的修改～
git show 356f6def9d3fb7f3b9032ff5aa4b9110d4cca87e
结果如下：
root@ubuntu:/android_src/packages/apps/Mms/src/com/android/mms/ui# git show 356f6def9d3fb7f3b9032ff5aa4b9110d4cca87e
commit 356f6def9d3fb7f3b9032ff5aa4b9110d4cca87e
Author: 某某某 <某某某的邮箱>
Date: Thu Jan 6 01:50:31 2011 +0800
修改的描述（是该代码commit时所填）
Signed-off-by: 某某某 <某某某的邮箱>
diff --git a/src/com/android/mms/ui/MessageItem.java b/src/com/android/mms/ui/MessageItem.java
index 0a0c4b7..55c3b27 100644
--- a/src/com/android/mms/ui/MessageItem.java
+++ b/src/com/android/mms/ui/MessageItem.java
+
+ 列出具体的改动
-
-
这样就可以知道是谁做了修改，以及具体的修改代码～
那接下来不管是直接去找他交流还是研究代码，都有依据了～
3.如果某个文件在你签出之后已经被别人修改，并且签入了，那么你在签入你的修改的时候， 如何合并不同的修改（merge)? 你用了什么工具来帮助你？
Git可以方便地对有简单不同的修改进行合并，但对于有逻辑冲突的部分将会给出conflict的提示，这时需要手工修改。
针对文件的不同状态（modified、untrack、conflict等）给出不同的颜色提示。
4.你有20个文件都是关于同一个功能的修改，你要如何保证这些文件都同时签入成功（修改的原子性），或者同时签入不成功？场景： 程序员果冻要签入 20 个文件，他一个一个地签入， 在签入完5 个 .h 文件之后， 他发现一些 .cpp 文件和最新的版本有冲突，他正在花时间琢磨如何合并... 这时候， 程序员小飞从客户端同步了所有最新代码， 开始编译， 但是编译不成功 - 因为有不同步的 .h 文件和 .cpp 文件！ 这时候， 别的程序员也来抱怨同样的问题，果冻应该怎么办？
在Git中，所有在本地仓库中修改的文件都要统一经过commit为新的本地版本后，再push至远程分支。这保障了本地修改提交的原子性，同时git服务器远程提供的修改操作也具有原子性。这样就保障了整体修改的原子性。
5.你的PC 上有关于三个功能的修改，但是都没有完成，有很多文件处于半完工的状态，这时你要紧急修改一个新的 bug，如何把本地修改放一边，保证在干净的环境中修改这个 bug, 并成功地签入你的修改 --- changelist management。
将远程工程clone到本地，然后在另一个git仓库中修改bug。
6.如何给你的源代码建立分支？场景：你们需要做一个演示，所以在演示版本的分支中对各处的代码做了一个临时的修改， 同时，主要的分支还保持原来的计划开发。 你们怎么做到的？ 在演示之后，演示版本的有些修改应该合并到主分支中，有些则不用，你们是怎么做到的？场景： 你们的软件发布了，有很多用户，一天，一个用户报告了一个问题，但是他们是用某个老版本，而且没有条件更新到最新版本。 这时候，你如何在本地构建一个老版本的软件，并试图重现那个问题？
首先为了演示fork一个新的分支保存演示版本代码，并且为了演示做的代码修改只会push到演示分支，而对于master分支的开发计划正常，进行只需要将原来的开发代码push到master分支即可。
演示之后进行合并分支操作。
$ git merge branchname
这个命令把分支"branchname"合并到了当前分支里面。
如有冲突（冲突——同一个文件在远程分支和本地分支里按不同的方式被修改了），在有问题的文件上会有冲突标记，手动按自己的需求修改有冲突文件的代码，在你手动解决完冲突后就可以把此文件添加到索引(index)中去，用git commit命令来提交，就像平时修改了一个文件一样。
$ git add file $ git commit
在执行合并命令即可。
根据用户报告的老版本的版本号，因为对每个发布版本都会建立一个分支保存其代码，检查git仓库中的历史发布版本中所包含的版本号，找到对应的commit记录以及hash值。
然后在本地
$ git clone
该分支，再使用
$ git reset --对应的版本hash值
命令退回到有bug的版本，修补该bug
7.一个源文件，如何知道它的每一行都是什么时候签入的，为了什么目的签入的 （解决了哪个任务，或者哪个bug）？场景： 一个重要的软件忽然出现崩溃的情况， 程序员果冻经过各种debug手段，发现问题是在某一个文件中有一行代码似乎显然出了问题，但是这个模块被很多其他模块调用，这行代码是什么时候，为了什么目的，经过谁签入的呢？如果贸然修改，会不会导致其他问题呢？ 怎么办？
8.如何给一个系统的所有源文件都打上标签，这样别人可以同步所有有这个标签的文件版本？代码每天都在变， 有时质量变好，有时变差，我们需要一个 Last Known Good （最后稳定的好版本） 版本， 这样新员工就可以同步这个版本， 我们如果需要发布，也是从这个版本开始。那么如何标记这个 Last Known Good 版本呢？
我们没有善用提交说明，以至于提交较为混乱。不过GIT中有这个功能。确保每次提交都有简明扼要的提交说明
9.你的项目的源代码和测试这些代码的单元测试，以及其他测试脚本都是放在一起的么？ 修改源代码会确保相应的测试也更新么？你的团队是否能部署自动构建的任务？在签入之前，程序员能否自动在自己的机器上运行自动测试，以保证本地修改不会影响整个软件的质量？在程序员提交签入之后，服务器上是否有自动测试程序， 完成编译，测试，如果成功，就签入，否则，就取消签入？团队是否配置了服务器，它自动同步所有文件，自动构建，自动运行相关的单元测试，碰到错误能自动发邮件给团队？
我们没有测试部分，因为时间紧促。