【10】進大廠必須掌握的面試題-版本控制面試
Q1。什麼是版本控制？
這可能是您在面試中最容易遇到的問題。我的建議是首先給出版本控制的定義。它是一個記錄一段時間內對一個文件或一組文件的更改的系統，以便您以後可以調用特定版本。版本控制系統由一個中央共享存儲庫組成，同事可以在其中對文件或文件集進行更改。然後，您可以提及版本控制的用途。
版本控制可讓您：
- 將文件還原到以前的狀態。
- 將整個項目還原到以前的狀態。
- 比較隨時間的變化。
- 查看誰最後修改了可能導致問題的內容。
- 誰修改了問題，何時修改了。
Q2。使用版本控制有什麼好處？
我建議您包括以下版本控制優點：
- 使用版本控制系統（VCS），允許所有團隊成員隨時自由處理任何文件。VCS稍後將允許您將所有更改合併到一個通用版本中。
- 所有過去的版本和變體都整齊地包裝在VCS中。在需要時，您可以隨時獲取任何版本，並且手邊將有完整項目的快照。
- 每次保存項目的新版本時，VCS都要求您提供更改內容的簡短描述。此外，您可以看到文件內容中的確切更改。這使您可以知道誰在項目中進行了哪些更改。
- 像Git這樣的分散式VCS允許所有團隊成員擁有完整的項目歷史記錄，因此，如果中央伺服器出現故障，則可以使用任何隊友的本地Git存儲庫。
Q3。在團隊中分支是怎麼用的。
詢問這個問題是為了測試您的分支經驗，因此請告訴他們您在上一份工作中使用分支的方式以及該分支的目的是什麼，您可以參考以下幾點：
- 特徵分支
特徵分支模型將特定特徵的所有更改保留在分支內。對功能進行全面測試並通過自動測試驗證後，該分支將合併到主伺服器中。 - 任務分支
在此模型中，每個任務都是在自己的分支上實現的，任務名稱包含在分支名稱中。很容易看到哪個程式碼實現了哪個任務，只需在分支名稱中查找任務鍵即可。 - 發布分支
一旦開發分支獲得了足夠的發布功能，就可以克隆該分支以形成發布分支。創建此分支將開始下一個發行周期，因此此刻之後不能添加任何新功能，該分支中僅應包含錯誤修復，文檔生成以及其他面向發行版的任務。一旦準備好發布，該發行版將合併到主版本中並標記一個版本號。此外，應該將其合併回developer分支，該分支可能從發行版開始就已經進行了。
最後告訴面試官，分支策略在一個組織之間會有所不同，所以我知道基本的分支操作，例如刪除，合併，簽出分支等。
Q4。您喜歡哪種VCS工具？
您可以僅提到您曾經使用過的VCS工具：「我從事過Git，與SVN等其他VCS工具相比，它具有一個主要優勢是它是一個分散式版本控制系統。」
分散式VCS工具不一定依賴中央伺服器來存儲項目文件的所有版本。相反，每個開發人員都「克隆」存儲庫的副本，並在其自己的硬碟上擁有項目的完整歷史記錄。
Q5。什麼是Git？
我建議您先解釋一下git的體系結構，以嘗試這個問題，如下圖所示。您可以參考以下說明：
- Git是一個分散式版本控制系統（DVCS）。它可以跟蹤對文件的更改，並允許您還原到任何特定的更改。
- 它的分散式體系結構提供了優於其他版本控制系統（VCS）的優勢，例如SVN，其中一個主要優點是它不依賴中央伺服器來存儲項目文件的所有版本。相反，每個開發人員都會「克隆」我在下圖中顯示的資源庫的副本和「本地資源庫」，並在其硬碟驅動器上具有項目的完整歷史記錄，以便在伺服器發生故障時恢復所需的一切。是您隊友的本地Git存儲庫之一。
- 還有一個中央雲存儲庫，開發人員可以在其中提交更改並與其他隊友共享，如您在圖中看到的，所有協作者都在提交更改「遠程存儲庫」。
Q6。解釋一些基本的Git命令？
以下是一些基本的Git命令：
Q7。在Git中，如何還原已經被推送並公開的提交？
這個問題可能有兩個答案，因此請確保同時包括這兩個原因，因為根據情況，可以使用以下任一選項：
- 在新的提交中刪除或修復錯誤的文件，然後將其推送到遠程存儲庫。這是修復錯誤的最自然的方法。對文件進行必要的更改後，將其提交到遠程存儲庫，因為我將使用
git commit -m「 commit message」 - 創建一個新的提交來撤消在錯誤的提交中所做的所有更改。為此，我將使用命令
git revert <錯誤的提交的名稱>
Q8。您如何將最後N次提交壓縮為一次提交？
有兩種方法可以將最後的N個提交壓縮為一個提交。在答案中包括以下兩個選項：
- 如果要從頭開始編寫新的提交消息，請使用以下命令
git reset –soft HEAD〜N &&
git commit - 如果要開始編輯包含現有提交消息的新提交消息，則需要提取這些消息並將其傳遞給Git提交，為此我將使用
git reset –soft HEAD〜N &&
git commit –edit -m 」 $（git log –format =％B –reverse .HEAD @ {N}）」
Q9。什麼是Git bisect？您如何使用它來確定（回歸）錯誤的來源？
我建議您首先給Git bisect一個小的定義，Git bisect用於通過二進位搜索來查找引入了bug的提交。Git bisect的命令是
**git bisect
**現在，既然您已經提到了上面的命令，請解釋該命令的作用。該命令使用二進位搜索演算法來查找項目歷史記錄中的哪個提交引入了錯誤。您通過首先告訴它包含臭蟲的「壞」提交和引入臭蟲之前的「好」提交來使用它。然後，Git bisect在這兩個端點之間選擇一個提交，並詢問您所選擇的提交是「好」還是「壞」。它會繼續縮小範圍，直到找到引入更改的確切提交為止。
Q10。什麼是Git rebase？如何在合併之前將其用於解決功能分支中的衝突？
據我說，您應該首先說git rebase是一個命令，它將把另一個分支合併到您當前正在工作的分支中，然後將所有在rebased分支之前的本地提交移動到該歷史的頂部科。
現在，您已經為示例定義了Git變基時間，以展示如何在合併之前使用它解決特徵分支中的衝突（如果從master創建了一個功能分支，並且從那時起master分支已收到新的提交，Git變基）可用於將要素分支移至母版的頂端。
該命令將有效地重放主節點頂端的功能分支中所做的更改，從而使衝突得以解決。謹慎完成後，這將使功能分支可以相對輕鬆地合併到master中，有時甚至可以作為簡單的快進操作。
Q11。您如何配置Git存儲庫以在提交之前運行程式碼完整性檢查工具，並在測試失敗後阻止它們？
我建議您先簡要介紹一下健全性檢查。健全性測試或冒煙測試確定了繼續測試是否可行和合理。
現在說明如何實現此目的，這可以通過與存儲庫的預提交掛鉤相關的簡單腳本來完成。在提交之前，甚至在要求您輸入提交消息之前，都會觸發預提交掛鉤。在此腳本中，可以運行其他工具，例如linters，並對提交到存儲庫中的更改執行完整性檢查。
Q12。您如何找到在特定提交中已更改的文件的列表？
對於此答案，而不僅僅是告訴命令，請解釋此命令的確切作用，這樣可以說：要獲取在特定提交中已更改的列表文件，請使用命令
git diff-tree -r {hash}
給定提交哈希，這將列出該提交中已更改或添加的所有文件。-r標誌使命令列出單個文件，而不是僅將它們摺疊為根目錄名稱。
您還可以包括以下提及的要點，儘管它是完全可選的，但將有助於打動面試官。
輸出還將包含一些額外的資訊，可以通過包含兩個標誌來輕鬆抑制它們：
git diff-tree –no-commit-id –name-only -r {hash}
在這裡，–no-commit-id將禁止在輸出中顯示提交哈希，並且–name-only將僅顯示文件名，而不是其路徑。
Q13。您如何設置一個腳本，以便每次存儲庫通過推送接收到新的提交時運行？
可以通過三種方式配置腳本，以便每次存儲庫通過推送接收到新的提交時都運行該腳本，一種方法是根據確切何時需要觸髮腳本來定義預接收，更新或後接收鉤子。
- 將提交推送到目標存儲庫中時，將調用預接收鉤子。綁定到此鉤子的任何腳本將在更新任何引用之前執行。這是運行有助於執行開發策略的腳本的有用鉤子。
- 更新掛鉤的工作方式與預接收掛鉤類似，並且在實際進行任何更新之前也會被觸發。但是，對於每次推送到目標存儲庫的提交，都會調用一次更新掛鉤。
- 最後，在將更新接受到目標存儲庫之後，將調用存儲庫中的接收後掛鉤。這是配置簡單部署腳本，調用某些持續集成系統，將通知電子郵件發送到存儲庫維護者等的理想場所。
掛鉤對於每個Git存儲庫都是本地的，並且沒有版本化。腳本可以在「 .git」目錄下的hooks目錄中創建，也可以在其他位置創建，並且可以將指向這些腳本的鏈接放在目錄中。
Q14。您如何在Git中知道分支是否已合併到master中？
我建議您同時包括以下兩個命令：
git branch –merged列出已合併到當前分支中的分支。
git branch –no-merged列出尚未合併的分支。
