小組名稱：飛天小女警
項目名稱：禮物挑選小工具
小組成員：沈柏杉（組長）、程媛媛、楊鈺寧、譚力銘
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.你的項目的源代碼和測試這些代碼的單元測試，以及其他測試腳本都是放在一起的么？ 修改源代碼會確保相應的測試也更新么？你的團隊是否能部署自動構建的任務？在簽入之前，程序員能否自動在自己的機器上運行自動測試，以保證本地修改不會影響整個軟件的質量？在程序員提交簽入之后，服務器上是否有自動測試程序， 完成編譯，測試，如果成功，就簽入，否則，就取消簽入？團隊是否配置了服務器，它自動同步所有文件，自動構建，自動運行相關的單元測試，碰到錯誤能自動發郵件給團隊？
我們沒有測試部分，因為時間緊促。