原文地址：https://medium.com/edureka/devops-interview-questions-e91a4e6ecbf3
原文作者：Saurabh Kulshrestha
翻譯君：CODING 戴維奧普斯
Q1：什麼是版本控制？
這可能是你在面試中遇到的最簡單的問題。我的建議是首先給出版本控制的定義：它是一個記錄文件變化的系統，以便你以後可以調用特定版本的文件。版本控制系統由一箇中央共享存儲庫組成，隊友可以在其中提交文件的更改，接下來你可以提到版本控制的用途。版本控制允許你：
- 將文件還原爲以前的狀態。
- 將整個項目還原爲以前的狀態。
- 比較一段時間內的變化。
- 查看最後一次修改可能導致問題的內容。
- 何時引入了問題。
Q2：使用版本控制有什麼好處？
版本控制的優點：
- 使用版本控制系統（VCS），所有團隊成員都可以隨時在任何文件上自由工作。VCS 允許你將所有更改合併到一個通用版本中。
- 所有過去的版本和變更都整齊地打包在 VCS 中。當你需要它時，你可以隨時請求任何版本，你將獲得完整項目的快照。
- 每次保存項目的新版本時，VCS 都要求你提供更改內容的簡短說明。此外，你還可以查看文件內容的確切更改內容。這可以讓你知道誰在項目中做了哪些更改。
- 像 Git 這樣的分佈式 VCS 允許所有團隊成員擁有項目的完整歷史記錄，因此如果中央服務器出現故障，你可以使用任何團隊成員的本地 Git 存儲庫來恢復代碼庫。
Q3：描述你使用的分支策略
這個問題用來測試你的分支經驗，所以告訴他們你在以前的工作中如何使用分支以及它的用途是什麼，你可以參考以下幾點：
- 特性分支
特性分支模型保留分支內特定功能的所有更改。當通過新增特性的全面測試和驗證時，該分支會被合併到 master 分支中。 - 任務分支
在此模型中，每個任務都在自己的分支上實現，任務關鍵詞包含在分支名稱中。只需在分支名稱中查找關鍵詞，就能很容易看出哪個代碼實現了哪個任務。 - 發佈分支
一旦開發分支爲發佈獲得了足夠的特性時，你就可以克隆該分支以形成發佈分支。創建此分支將啓動下一個發佈週期，因此在這之後不能添加任何新功能，只有錯誤修復、文檔補齊和其它面向發佈的任務能夠包含在此分支中。一旦準備好發佈，該版本將合併到 master 中並標記版本號。此外，儘管自發布以來開發分支可能已經有新的代碼更新，但它依然應該被合併回開發分支。
最後告訴他們分支策略因組織而異，所以我知道基本的分支操作：如刪除，合併，檢出分支等。
Q4：你熟悉哪種 VCS 工具？
你可以提到你曾經使用的 VCS 工具：“我使用過 Git，它對比 SVN 等其他 VCS 工具的一個主要優勢在於，它是一個分佈式版本控制系統。”
分佈式 VCS 工具不一定依靠中央服務器來存儲項目文件的所有版本。相反，每個開發人員都“克隆”存儲庫的副本，並在自己的硬盤上擁有項目的完整歷史記錄。
Q5：什麼是 Git？
我建議你通過解釋 Git 的體系結構來解答這個問題，如下圖所示。你可以參考下面給出的解釋：
- Git 是一個分佈式版本控制系統（DVCS），它可以跟蹤文件的更改，並允許你恢復任何特定的更改。
- 與 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 commit 。我會使用：
**git reset -soft HEAD~N && **
git commit -edit -m “$（git log -format =％B -reverse .HEAD @ {N}）”
Q9：什麼是 Git bisect？如何用它來確定 bug 的來源？
我建議你先給出一個 Git bisect 的小定義——Git bisect 用於通過二進制搜索算法來查找引入 bug 的提交。Git bisect 的命令是：
git bisect <子命令>
接下來需要解釋一下這個命令可以做什麼，這個命令使用二進制搜索算法來查找項目歷史中哪個提交引入了一個 bug。首先你需要告訴它一個已知的包含了該 bug 的提交和在一個已知的引入 bug 之前的提交。然後 Git bisect 在這兩個時間點之間選擇一個提交，並詢問你所選的提交是“好”還是“壞”，之後它繼續縮小範圍，直到找到引入 bug 的確切提交。
Q10：什麼是 Git rebase？它如何在合併之前解決特性分支中的衝突？
你應該首先說 Git rebase 是一個命令，它將另一個分支合併到當前你正在工作的分支中，並將所有位於另一分支之前的本地提交，移到該當前工作分支歷史記錄頂部。
接下來你需要通過一個示例定義 Git rebase 時間窗，以顯示如何在合併之前使用它來解決特性分支中的衝突。如果從 master 創建了一個特性分支，那麼 master 已經收到了新的提交，Git rebase 可用於將特性分支移動到 master 分支的頂部。
該命令有效地在 master 的頂部重放特性分支中所做的更改，並允許在該過程中解決衝突。完成後，特性分支會相對容易地合併到 master 中，有時會被作爲簡單的快進操作。
Q11：如何配置 Git 存儲庫，以在提交之前運行代碼健康性檢查工具，並在測試失敗時阻止提交？
我建議你先簡要介紹一下合理性檢查。合理性或冒煙測試可以用來確定是否進行後續測試的合理性和必要性。
接下來解釋如何實現這一點，這可以通過與存儲庫的預提交鉤子相關的簡單腳本來完成。即使在你需要輸入提交消息之前，也會在提交之前觸發預提交掛鉤。在此腳本中，可以運行其它工具，例如 linters，並對提交到存儲庫中的更改執行完整性檢查。
最後給出一個例子，你可以參考下面的腳本：
#!/bin/sh
files=$(git diff -cached -name-only -diff-filter=ACM | grep '.go$')
if [ -z files ]; then
exit 0
fi
unfmtd=$(gofmt -l $files)
if [ -z unfmtd ]; then
exit 0
fi
echo "Some .go files are not fmt'd"
exit 1
此腳本會檢查即將提交的所有 .go 文件是否通過標準 Go 源碼格式化工具 —— gofmt 的檢驗。當檢查未通過時，通過以非零狀態退出，腳本能有效地阻止該提交應用於存儲庫。
Q12：如何找到特定提交中已更改的文件列表？
對於這個問題，不應該僅僅只解釋這個命令是什麼，而應該解釋這個命令究竟會做什麼。所以你可以這麼說，爲了獲得在特定提交中更改的文件列表使用命令：
git diff-tree -r {hash}
給定提交哈希值，這個命令將列出在該提交中更改或添加的所有文件。-r 標誌會讓命令列出各個文件，而不是僅將它們摺疊到根目錄名稱中。
你的回答也可以包含以下內容，雖然它是完全可選的，但有助於給面試官留下深刻的印象：
輸出還將包含一些額外信息，可以通過以下兩個標誌輕鬆去掉：
git diff-tree -no-commit-id -name-only -r {hash}
這裏 -no-commit-id 將禁止提交哈希值出現在輸出中，而 -name-only 只會打印文件名而不是它們的路徑。
Q13：每次存儲庫接收到新推送的提交時，如何設置某些特定腳本運行？
每次存儲庫接收到開發者 push 的新提交時，有三種方法可以配置腳本運行，需要根據觸發腳本的時間來定義 pre-receive、update、或者 post-receive 腳本。
- 當有新提交被 push 到目標存儲庫時，將調用目標存儲庫中的 pre-receive 鉤子腳本。綁定到此掛鉤的任何腳本都將在更新任何引用之前執行。這是一個很有用的鉤子，可以用於運行有助於實施開發策略的腳本。
- update 鉤子以類似 pre-receive 鉤子的方式工作，並且在實際進行任何更新之前也會觸發。但是對於已推送到目標存儲庫的每個提交，都會調用一次 update 鉤子。
- 最後，在將更新接受到目標存儲庫後，將調用存儲庫中的 post-receive 鉤子。這是配置簡單部署腳本、調用持續集成系統、向存儲庫維護人員發送通知電子郵件等事務的理想場所。
鉤子是每個 Git 存儲庫的本地存儲，並且沒有版本化。腳本可以在“.git”目錄內的 hooks 目錄中創建，也可以在別處創建，並且可以在目錄中放置這些腳本的鏈接。
Q14：如何知道分支是否已經合併入主分支？
我建議你提到以下命令：
git branch -merged 列出已合併到當前分支的分支。
git branch -no-merged 列出了尚未合併的分支。