2019 DevOps 必備面試題——代碼版本控制篇

原文地址:medium.com/edureka/dev…
原文做者:Saurabh Kulshrestha
翻譯君:CODING 戴維奧普斯git

Q1:什麼是版本控制?

這多是你在面試中遇到的最簡單的問題。個人建議是首先給出版本控制的定義:它是一個記錄文件變化的系統,以便你之後能夠調用特定版本的文件。版本控制系統由一箇中央共享存儲庫組成,隊友能夠在其中提交文件的更改,接下來你能夠提到版本控制的用途。版本控制容許你:面試

  • 將文件還原爲之前的狀態。
  • 將整個項目還原爲之前的狀態。
  • 比較一段時間內的變化。
  • 查看最後一次修改可能致使問題的內容。
  • 什麼時候引入了問題。

Q2:使用版本控制有什麼好處?

版本控制的優勢:算法

  1. 使用版本控制系統(VCS),全部團隊成員均可以隨時在任何文件上自由工做。VCS 容許你將全部更改合併到一個通用版本中。
  2. 全部過去的版本和變動都整齊地打包在 VCS 中。當你須要它時,你能夠隨時請求任何版本,你將得到完整項目的快照。
  3. 每次保存項目的新版本時,VCS 都要求你提供更改內容的簡短說明。此外,你還能夠查看文件內容的確切更改內容。這可讓你知道誰在項目中作了哪些更改。
  4. 像 Git 這樣的分佈式 VCS 容許全部團隊成員擁有項目的完整歷史記錄,所以若是中央服務器出現故障,你可使用任何團隊成員的本地 Git 存儲庫來恢復代碼庫。

Q3:描述你使用的分支策略

這個問題用來測試你的分支經驗,因此告訴他們你在之前的工做中如何使用分支以及它的用途是什麼,你能夠參考如下幾點:bash

  • 特性分支 特性分支模型保留分支內特定功能的全部更改。當經過新增特性的全面測試和驗證時,該分支會被合併到 master 分支中。
  • 任務分支 在此模型中,每一個任務都在本身的分支上實現,任務關鍵詞包含在分支名稱中。只需在分支名稱中查找關鍵詞,就能很容易看出哪一個代碼實現了哪一個任務。
  • 發佈分支 一旦開發分支爲發佈得到了足夠的特性時,你就能夠克隆該分支以造成發佈分支。建立此分支將啓動下一個發佈週期,所以在這以後不能添加任何新功能,只有錯誤修復、文檔補齊和其它面向發佈的任務可以包含在此分支中。一旦準備好發佈,該版本將合併到 master 中並標記版本號。此外,儘管自發布以來開發分支可能已經有新的代碼更新,但它依然應該被合併回開發分支。

最後告訴他們分支策略因組織而異,因此我知道基本的分支操做:如刪除,合併,檢出分支等。服務器

Q4:你熟悉哪一種 VCS 工具?

你能夠提到你曾經使用的 VCS 工具:「我使用過 Git,它對比 SVN 等其餘 VCS 工具的一個主要優點在於,它是一個分佈式版本控制系統。」架構

分佈式 VCS 工具不必定依靠中央服務器來存儲項目文件的全部版本。相反,每一個開發人員都「克隆」存儲庫的副本,並在本身的硬盤上擁有項目的完整歷史記錄。分佈式

Q5:什麼是 Git?

我建議你經過解釋 Git 的體系結構來解答這個問題,以下圖所示。你能夠參考下面給出的解釋:工具

  • Git 是一個分佈式版本控制系統(DVCS),它能夠跟蹤文件的更改,並容許你恢復任何特定的更改。
  • 與 SVN 等其它版本控制系統相比,它的分佈式架構具備許多優點,一個主要優勢是它不依賴於中央服務器來存儲項目文件的全部版本。相反,每一個開發人員「克隆」我在下圖中使用「本地存儲庫」顯示的存儲庫副本,並在其硬盤驅動器上具備項目的完整歷史記錄,以便在出現服務器中斷時,能從你的某位隊友的本地 Git 存儲庫中恢復所需的所有內容。
  • 還有一箇中央雲存儲庫,開發人員能夠提交更改並與其餘團隊成員共享。如圖所示,全部協做者都提交更改至「遠程存儲庫」。

圖片

Q6:解釋一些基本的 Git 命令?

如下是一些基本的 Git 命令:post

圖片

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 列出了還沒有合併的分支。

相關文章
相關標籤/搜索