0、在吹牛之前，先回答這個問題： 如果你的團隊來了一個新隊員，有一臺全新的機器， 你們是否有一個文檔，只要設置了相應的權限，她就可以根據文檔，從頭開始搭建環境，并成功地把最新、最穩定版本的軟件編譯出來，并運行必要的單元測試？ （在這過程中，不需要和老隊員做任何交流）

將代碼傳到coding上。

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

所有人都可以自由的簽出源代碼。

場景： 程序員果凍正在對幾個文件進行修改，實現一個大的功能， 這時候，程序員小飛也要改其中一個文件，快速修復一個問題。怎么辦？一個代碼文件被簽出 (check out) 之后，另一個團隊成員可以簽出這個文件，并修改，然后簽入么？有幾種設計，各有什么優缺點？

設計一：簽出文件后，此文件就加鎖，別人無法簽出；優點：多人修改一個代碼不會發生沖撞，缺點：鎖定后別人無法再修改代碼。 設計二：所有人都可以自由簽出文件；優點：所有人都將可以對代碼進行修改，提高效率，缺點：可能導致代碼的編寫流程混亂，發生沖撞。

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

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

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

我們團隊主要是使用Coding來進行源代碼管理。 Coding會保留每一次的commit記錄，并且對每一次更改的部分標識。

3. 如果某個文件在你簽出之后已經被別人修改，并且簽入了，那么你在簽入你的修改的時候， 如何合并不同的修改（merge)? 你用了什么工具來幫助你？

我們團隊主要是使用Coding來進行源代碼管理。 首先，在進行文件修改之前，在群里聲明自己正在進行工作，修改什么文件，盡量避免同時簽入發生的沖突。 如果一定要同時進行一個文件的修改，修改代碼時，不要改動你簽出文件中他人的方法，如必需改動的，請與該方法作者協商。注意簽入文件的時候用commit -m添加文件的注釋，讓大家都清晰明了你修改的部分。 并且工作時根據需要，簽出你所需要修改的代碼，不要簽出所有代碼。

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

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

在簽入之前應保證自己的文件能通過編譯，而不是上傳有問題的.cpp和.h，先保證自己不出問題再獲取其他人的簽入，然后再看是否能夠通過編譯。如果不能，請找簽入的同學告知情況并解決問題，再簽入和編譯。

5. 你的PC 上有關于三個功能的修改， 但是都沒有完成，有很多文件處于半完工的狀態，這時你要緊急修改一個新的 bug，如何把本地修改放一邊，保證在干凈的環境中修改這個 bug, 并成功地簽入你的修改 --- changelist management。

沒有遇到過，不過假如遇到可以使用Git里的stash命令將當前的狀態暫時封存起來，這個時候再進行對Bug修復的代碼簽入。

6. 規范操作和自動化。你的團隊規定開發者簽入的時候要做這些事情：- 運行單元測試，相關的代碼質量測試。- 代碼復審 （要有別的員工的名字）- 和這次簽入相關的issue 編號， 任務/task， 缺陷/bug 編號，等等， 以備查詢。請問你的團隊有這樣的自動化工具讓開發者方便地一次性填入所有信息然后提交么？ （高級功能， 代碼提交之后， 相關bug 的狀態會改動為 “fixed”， 并且有鏈接指向這次簽入。）

沒有

7. 如何給你的源代碼建立分支？

在Git上創建一個develop分支,在develop分支上進行開發 然后在develop上附屬創建一些特性分支,比比如我們可 以為登陸功能創建一個login分支,為注冊功能創建一個register分支, 為用戶管理創建一個user分支,這些功能分支都屬于feature分支。

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

場景： 一個重要的軟件歷經幾年，幾個團隊的開發和維護，忽然出現在某個條件下崩潰的事故， 程序員果凍經過各種debug手段，發現問題是在某一個文件中有一行代碼似乎顯然出了問題，但是這個模塊被很多其他模塊調用，這行代碼是什么時候，為了什么目的，經過誰簽入的呢？如果貿然修改，會不會導致其他問題呢？怎么辦？

剛開始建立的團隊項目會提交到coding上面，之后修改后會再次提交，會產生新的時間戳，現在如果要查看這行代碼是什么時候簽入的或者是誰簽入的就可以看到記錄；從代碼注釋里面或者上下文就可以看到為了什么目的簽入的。 如果貿然修改的話會影響源代碼的整體性、邏輯性和結構性，這時候可以聯系簽入者，商量解決之。

9. 如何給一個系統的所有源文件都打上標簽，這樣別人可以同步所有有這個標簽的文件版本？代碼每天都在變， 有時質量變好，有時變差，我們需要一個 Last Known Good （最后穩定的好版本） 版本，這樣新員工就可以同步這個版本，我們如果需要發布,也是從這個版本開始。那么如何標記這個 Last Known Good 版本呢？

創建一個新的文件夾，然后將這個穩定的版本放進去，再將文件名修改為一個比較通俗一點的名字，讓使用者一眼就能看出這是Last Known Good版本。

10. 你的項目的源代碼和測試這些代碼的單元測試，以及其他測試腳本都是放在一起的么？ 修改源代碼會確保相應的測試也更新么？你的團隊是否能部署自動構建的任務？在簽入之前，程序員能否自動在自己的機器上運行自動測試，以保證本地修改不會影響整個軟件的質量？在程序員提交簽入之后，服務器上是否有自動測試程序， 完成編譯，測試，如果成功，就簽入，否則，就取消簽入？團隊是否配置了服務器，它自動同步所有文件，自動構建，自動運行相關的單元測試，碰到錯誤能自動發郵件給團隊

我們項目的源代碼和測試這些代碼的單元測試，以及其他測試腳本不是放在一起的，是分開的，這樣比較能方便管理，易于修改和測試腳本。 修改源代碼會確保相應的測試也能更新的。 我們的團隊能不輸自動構建的任務的。

轉載于:https://www.cnblogs.com/rgxz/p/6872343.html

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的关于源代码管理的10 个问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。