Git源代碼管理

0.若是你的團隊來了一個新隊員，有一臺全新的機器， 大家是否有一個文檔，只要設置了相應的權限，她就能夠根據文檔，從頭開始搭建環境，併成功地把最新、最穩定版本的軟件編譯出來，並運行必要的單元測試？ （在這過程當中，不須要和老隊員作任何交流）

 

咱們有相應文檔，只要按照文檔要求，學習預備知識、搭建開發環境、同步最新代碼並啓動服務，並對沒法正常服務的幾種可能緣由進行調試，大多數狀況下，能夠將最新、最穩定版本的軟件編譯出來。

文檔地址是：

https://github.com/buaaclubs-team/share-and-notify/wiki/%E5%86%99%E7%BB%99%E6%96%B0%E4%BA%BA%E7%9A%84%E6%8C%87%E5%AF%BC

 

1. 你的團隊的源代碼控制在哪裏？用的是什麼系統？如何處理文件的鎖定問題？

   場景：  程序員果凍正在對幾個文件進行修改，實現一個大的功能， 這時候， 程序員小飛也要改其中一個文件，快速修復一個問題。怎麼辦？

    一個代碼文件被簽出 (check out) 以後，另外一個團隊成員能夠簽出這個文件，並修改，而後簽入麼？

   有幾種設計，各有什麼優缺點？

   例如，簽出文件後，此文件就加鎖，別人沒法簽出；  或者， 全部人均可以自由簽出文件

 

　　

　咱們團隊的源代碼控制在Github上，使用的是git提供的一系列服務。

　關於文件的鎖定方面，咱們運用的是git的機制，就是任何人均可以在任什麼時候刻將一個代碼文件簽出，可是，遷入的時候是須要先pull的。就是說，每次遷入的時候，都須要保證當前本身的代碼是已經合併了遠端的代碼，也就能夠保證每次遷入的必定是最新的。

 

2. 如何看到這個文件和以前版本的差別？ 如何看到代碼修改和工做項 （work item），缺陷修復 （bug fix) 的關係。

   場景： 程序員果凍看到某個文件被修改了，他怎麼看到這個文件在最近的修改究竟改了哪些地方？ 

   場景： 程序員果凍看到某個文件在最新版本被改動了100 多行， 那麼和這100多行對應的其餘修改在什麼文件中呢？ 這個修改是爲了解決哪些問題而做的呢？ 那些問題有工做項 （work item，issue），或者bug 來跟蹤麼？

 

   

  2.1  查看版本的差別

 

咱們在紅色框框裏能夠看到改變的文件

 

 

彩色的部分是添加或者修改的部分

 

2.2 Issue的用途

咱們到官網上看看issue的用途吧~

 

issue能夠很好的跟蹤任務，進度，bugs的狀況。咱們使用issue來管理咱們的任務，進度和bugs。

 

2.3 github上commit與issue關聯

a.首先，咱們先創建一個issue吧~

點擊new issue

 

 

創建新的issue後，咱們能夠在issues裏看到全部建好的issue

箭頭指向的就是咱們新建的issue喲~

 

 

 

b.在commit時，關聯issue

在commit的時候，commit message寫上issue #[issue號]

若是要是命令行的話，就是 git commit -m ‘Issue #6: [能夠加上你本身的Description]’

 

 

 

c.push以後，咱們即可以看到，咱們剛剛的commit關聯了Issue #6

 

 

d.點擊#6，咱們就能夠看到在該issue下面有咱們的修改~

 

 

e.若是該issue已經完成，咱們能夠點擊close issue

 

以後，該issue算已經完成啦

 

 3. 若是某個文件在你簽出以後已經被別人修改，而且簽入了，那麼你在簽入你的修改的時候， 如何合併不一樣的修改（merge)? 你用了什麼工具來幫助你？

　　通常狀況下，git pull將遠程代碼pull到本地後，git會按照默認的合併規則，自動對修改進行合併。其中，對於沒法自動合併的狀況，git會在發生衝突的地方打上標記，使用華麗麗分割線將發生衝突的代碼分割開來，而後咱們須要作的就是手動對這些修改進行合併，選擇保留哪些內容，刪除哪些內容，最後，從新add，commit，再將你的修改push上去。

　　在後端的編寫中，後端三我的各自負責不一樣的模塊，基本上沒有發生衝突的問題。可是在編寫數據庫遷移文件時，三我的都寫了一部份數據庫的遷移，這在合併到master分支上出現了一些問題。並且因爲咱們的代碼不是一次寫好的，總會存在許多問題，因此若是都push到master分支上，就會使master分支上的代碼有許多問題，而後我又會把別人有問題的代碼pull到本身本地，這樣你們的代碼都是會變得有問題了。

　　爲此，咱們後端的解決方法就是，首先由一我的將數據庫遷移所有寫好，放到master分支上，以後的人在寫代碼的時候就沒有必要再去寫數據庫遷移了。以後你們clone master分支上的代碼，並在遠程創建各自的分支，push到本身的分支上去，最後再合併到master分支上。這樣作有許多好處：因爲三我的寫的部分相關性不是很密切，因此並不關心別人寫的代碼，其次這樣保證master分支上的代碼是穩定的版本，至少是沒有錯誤的。最後，你們，能夠天天遷入代碼，沒必要每次都要pull別人有問題的代碼了，並且即便本身目前的代碼有問題，也不會影響到其餘人。

4. 你有20個文件都是關於同一個功能的修改，你要如何保證這些文件都同時簽入成功（修改的原子性），或者同時簽入不成功？

    場景： 程序員果凍要簽入 20 個文件，他一個一個地簽入， 在簽入完5 個 .h 文件以後， 他發現一些 .cpp 文件和最新的版本有衝突，他正在花時間琢磨如何合併... 這時候， 程序員小飛從客戶端同步了全部最新代碼， 開始編譯， 可是編譯不成功 - 由於有不一樣步的 .h 文件和 .cpp 文件！  這時候， 別的程序員也來抱怨一樣的問題，果凍應該怎麼辦？

　　

　　咱們統一採用git將本地代碼上傳至github。

　　Git 在每次上傳以前會檢查遠程分支，若是已更新而本地未同步，它會要求用戶先pull同步後，再進行Push。因此不存在情景中提到的的情況。

而在經過git push 將本地代碼上傳以前，均須要將本地的改變提交至本地倉庫，commit操做會生成一個commit對象，因此Push時只是將此次commit對象提交至遠程分支。而git會隨時保證數據的完整性，一旦上傳過程當中出現問題（斷網），會撤銷掉以前的上傳記錄。

5. 你的PC 上有關於三個功能的修改，可是都沒有完成，有不少文件處於半完工的狀態，這時你要緊急修改一個新的 bug，如何把本地修改放一邊，保證在乾淨的環境中修改這個 bug, 併成功地簽入你的修改 --- changelist management。

　　先另外創建一個分支，經過git pull將遠程分支代碼拉到本地進行BUG修改，以後在同以前的分支進行合併，在經過git push上傳至遠程分支。

6. 如何給你的源代碼創建分支？

    場景：大家須要作一個演示，因此在演示版本的分支中對各處的代碼作了一個臨時的修改， 同時，主要的分支還保持原來的計劃開發。 大家怎麼作到的？ 在演示以後，演示版本的有些修改應該合併到主分支中，有些則不用，大家是怎麼作到的？

    場景： 大家的軟件發佈了，有不少用戶，一天，一個用戶報告了一個問題，可是他們是用某個老版本，並且沒有條件更新到最新版本。 這時候，你如何在本地構建一個老版本的軟件，並試圖重現那個問題？

 

　　

　　創建分支利用git branch 分支名 操做，跳轉到相應分支用git check out 操做，分支合併用git merge 操做，在確認了修改之後，進行git commit 操做提交。

　　場景一：能夠用git branch demo 創建一個新的分支，把主分支（main）裏的東西clone到新的分支裏進行修改，在修改完以後，用git checkout main 進入到main分支，而後用git merge demo 命令進行合併，選擇須要保留的內容，最後用git commit 命令提交修改。

　　場景二：每一次提交都會有一個commit代碼，好比某次提交的名字是alpha，如今版本是beta版本，只須要git checkout 到alpha分支下，而後運行用戶提示的問題，既能夠再現問題。

7. 一個源文件，如何知道它的每一行都是何時簽入的，爲了什麼目的簽入的 （解決了哪一個任務，或者哪一個bug）？

   場景： 一個重要的軟件突然出現崩潰的狀況，  程序員果凍通過各類debug手段，發現問題是在某一個文件中有一行代碼彷佛顯然出了問題，可是這個模塊被不少其餘模塊調用，這行代碼是何時，爲了什麼目的，通過誰簽入的呢？若是貿然修改，會不會致使其餘問題呢？ 怎麼辦？

　　

　　咱們能夠經過github提供的功能來得知代碼的行是在何時遷入的，遷入的目的等。

　　咱們能夠知道當前的這些代碼是如何被修改的，以下圖所示：

 　　

　　另外咱們能夠經過文件後面來知道每一個文件最後是由誰，在哪一個commit修改的，以下圖所示：

　

8. 如何給一個系統的全部源文件都打上標籤，這樣別人能夠同步全部有這個標籤的文件版本？

   代碼天天都在變， 有時質量變好，有時變差，咱們須要一個 Last Known Good （最後穩定的好版本） 版本， 這樣新員工就能夠同步這個版本， 咱們若是須要發佈，也是從這個版本開始。那麼如何標記這個 Last Known Good 版本呢？ 

　

　　git標籤

 

　　標籤經常用在標記某個歷史狀態的關鍵點，通常用版本號例如v1.1或者日期1222等具備標誌性的簡單標記來記錄。

　　咱們建立標籤號的時候使用v1.2這種格式的，當咱們寫出一個Last Known Good （最後穩定的好版本） 版本的時候，咱們會在此次的標籤後加上後-lkg綴表示

　　這個是lask known good版本，

　　(1).列出git中現有的標籤

　　git tag

　　結果會顯示全部標籤

 

　　(2).查找特定序列的標籤

　　git tag -l v1.2.*

　　結果會顯示 v1.2.3 v1.2.4等等之類符合格式的標籤

 

　　(3).建立標籤

　　git tag -a v1.1 -m 'version 1.1'

　　-m是標籤信息

 

　　(4).建立標籤成功後能夠查看信息

　　git show v1.1

 

　　(5).建立輕量級標籤

　　git tag v1.2

　　什麼都不加，使用git show查看的時候不會顯示那麼多信息

 

　　(6).對以前某次提交貼個標籤

　　git tag -a v1.3 8d8ds3r

　　後面跟上那次提交的校驗和或者部分校驗和便可。

 

　　(7).共享標籤

　　在push的時候默認不會將標籤上傳到遠程服務器上，因此要

　　git push --tags

　　這樣會將全部標籤一併傳到服務器上，別人在克隆或者同步git倉庫的話，標籤也會獲取下來

 

　　(8).push指定標籤

　　git push v1.2

 

　　(9).查看指定標籤的代碼狀態

　　git checkout v1.2

 

　　(10).恢復代碼到某個標籤點

　　在git show以後獲取校驗值，而後經過git reset回退代碼

 

　　(11).刪除標籤

　　git tag -d 制定標籤

 

　　好比把本次提交了tag文檔以後的倉庫加一個標籤

　　首先

　　git tag v1.1

　　建立了一個新的v1.1標籤，而後

　　git show v1.1

　　查看了標籤信息和內容(?爲中文)，而後

　　git push v1.1

　　把本標籤下的文件push上去

　　提交以後的v1.1標籤裏的內容以下

9. 你的項目的源代碼和測試這些代碼的單元測試，以及其餘測試腳本都是放在一塊兒的麼？ 修改源代碼會確保相應的測試也更新麼？你的團隊是否能部署自動構建的任務？

    在簽入以前，程序員可否自動在本身的機器上運行自動測試，以保證本地修改不會影響整個軟件的質量？

    在程序員提交簽入以後，服務器上是否有自動測試程序， 完成編譯，測試，若是成功，就簽入，不然，就取消簽入？

    團隊是否配置了服務器，它自動同步全部文件，自動構建，自動運行相關的單元測試，碰到錯誤能自動發郵件給團隊

 

　　單元測試的代碼是和項目的源代碼放在一塊兒的，由於rails自帶單元測試框架，放在test目錄下，test/model下存放的是模型的單元測試，test/controller目錄下存放的是編寫的功能測試，修改源代碼後要運行以前的測試，只有以前的測試都經過後，才能push代碼到遠程。

　　咱們目前並無作自動測試的設置，須要手動輸入rake test指令執行測試用例。