關於 Git 的 20 個面試題[每日前端夜話0x75]

時間 2021-02-02

標籤前端 git 面試算法服務器架構分佈式 ide 工具測試欄目 Git 简体版

原文原文鏈接

關於 Git 的 20 個面試題[每日前端夜話0x75]

瘋狂的技術宅前端先鋒前端

每日前端夜話0x75
每日前端夜話，陪你聊前端。
天天晚上18:00準時推送。
正文共：3604 字
預計閱讀時間： 10 分鐘
翻譯：瘋狂的技術宅
來源：edurekagit

我在工做中很喜歡 Git 。 Git 在許多開發團隊中扮演着重要的角色。面試

關於 Git 面試的第一個問題必須是：算法

Q1. Git和SVN有什麼區別？

Q2. 什麼是Git？

我建議你先經過了解 git 的架構再來回答這個問題，以下圖所示，試着解釋一下這個圖：服務器

Git 是分佈式版本控制系統（DVCS）。它能夠跟蹤文件的更改，並容許你恢復到任何特定版本的更改。
與 SVN 等其餘版本控制系統（VCS）相比，其分佈式架構具備許多優點，一個主要優勢是它不依賴於中央服務器來存儲項目文件的全部版本。
每一個開發人員均可以「克隆」我在圖中用「Local repository」標註的存儲庫的副本，而且在他的硬盤驅動器上具備項目的完整歷史記錄，所以當服務器中斷時，你須要的全部恢復數據都在你隊友的本地 Git 存儲庫中。
還有一箇中央雲存儲庫，開發人員能夠向其提交更改，並與其餘團隊成員進行共享，如圖所示，全部協做者都在提交更改「遠程存儲庫」。

Git 架構
Q3. 在 Git 中提交的命令是什麼？

答案很是簡單。
用於寫入提交的命令是 git commit -a。架構

如今解釋一下 -a 標誌，經過在命令行上加 -a 指示 git 提交已修改的全部被跟蹤文件的新內容。還要提一下，若是你是第一次須要提交新文件，能夠在在 git commit -a 以前先 git add <file>。分佈式

Q4. 什麼是 Git 中的「裸存儲庫」？

你應該說明「工做目錄」和「裸存儲庫」之間的區別。ide

Git 中的「裸」存儲庫只包含版本控制信息而沒有工做文件（沒有工做樹），而且它不包含特殊的 .git 子目錄。相反，它直接在主目錄自己包含 .git 子目錄中的全部內容，其中工做目錄包括：工具

一個 .git 子目錄，其中包含你的倉庫全部相關的 Git 修訂歷史記錄。
工做樹，或簽出的項目文件的副本。
Q5. Git 是用什麼語言編寫的？

你須要說明使用它的緣由，而不只僅是說出語言的名稱。我建議你這樣回答：測試

Git使用 C 語言編寫。 GIT 很快，C 語言經過減小運行時的開銷來作到這一點。

Q6. 在Git中，你如何還原已

經 push 並公開的提交？

There can be two answers to this question and make sure that you include both because any of the below options can be used depending on the situation: 1
這個問題能夠有兩個答案，你回答時也要保包含這兩個答案，由於根據具體狀況可使用如下選項：

刪除或修復新提交中的錯誤文件，並將其推送到遠程存儲庫。這是修復錯誤的最天然方式。對文件進行必要的修改後，將其提交到我將使用的遠程存儲庫

1git commit -m "commit message"

建立一個新的提交，撤消在錯誤提交中所作的全部更改。可使用命令：

1git revert <name of bad commit>

Q7. git pull 和 git fetch 有什麼區別？

git pull 命令從中央存儲庫中提取特定分支的新更改或提交，並更新本地存儲庫中的目標分支。

git fetch 也用於相同的目的，但它的工做方式略有不一樣。當你執行 git fetch 時，它會從所需的分支中提取全部新提交，並將其存儲在本地存儲庫中的新分支中。若是要在目標分支中反映這些更改，必須在 git fetch 以後執行git merge。只有在對目標分支和獲取的分支進行合併後纔會更新目標分支。爲了方便起見，請記住如下等式：

git pull = git fetch + git merge

Q8. git中的「staging area」或「index」是什麼？

For this answer try to explain the below diagram as you can see:
能夠經過下圖進行解釋：

在完成提交以前，能夠在稱爲「staging area」或「index」的中間區域中對其進行格式化和審查。從圖中能夠看出，每一個更改首先在暫存區域中進行驗證，我將其稱爲「stage file」，而後將更改提交到存儲庫。

Staging Area

Q9. 什麼是 git stash?

首先應該解釋 git stash 的必要性。

一般狀況下，當你一直在處理項目的某一部分時，若是你想要在某個時候切換分支去處理其餘事情，事情會處於混亂的狀態。問題是，你不想把完成了一半的工做的提交，以便你之後就能夠回到當前的工做。解決這個問題的答案是 git stash。

再解釋什麼是git stash。

stash 會將你的工做目錄，即修改後的跟蹤文件和暫存的更改保存在一堆未完成的更改中，你能夠隨時從新應用這些更改。

Q10. 什麼是git stash drop？

經過說明咱們使用 git stash drop 的目的來回答這個問題。

git stash drop 命令用於刪除隱藏的項目。默認狀況下，它將刪除最後添加的存儲項，若是提供參數的話，它還能夠刪除特定項。

下面舉個例子。

若是要從隱藏項目列表中刪除特定的存儲項目，可使用如下命令：

git stash list：它將顯示隱藏項目列表，如：

stash@{0}: WIP on master: 049d078 added the index file
stash@{1}: WIP on master: c264051 Revert 「added file_size」
stash@{2}: WIP on master: 21d80a5 added number to log

若是要刪除名爲 stash@{0} 的項目，請使用命令 git stash drop stash@{0}。

Q11. 如何找到特定提交中已更改的文件列表？

對於這個問題，不能僅僅是提供命令，還要解釋這個命令究竟作了些什麼。

要獲取特定提交中已更改的列表文件，請使用如下命令：

git diff-tree -r {hash}

給定提交哈希，這將列出在該提交中更改或添加的全部文件。 -r 標誌使命令列出單個文件，而不是僅將它們摺疊到根目錄名稱中。

你還能夠包括下面提到的內容，雖然它是可選的，但有助於給面試官留下深入印象。

輸出還將包含一些額外信息，能夠經過包含兩個標誌把它們輕鬆的屏蔽掉：

git diff-tree –no-commit-id –name-only -r {hash}

這裏 -no-commit-id 將禁止提交哈希值出如今輸出中，而 -name-only 只會打印文件名而不是它們的路徑。

Q12. git config 的功能是什麼？

首先說明爲何咱們須要 git config。

git 使用你的用戶名將提交與身份相關聯。 git config 命令可用來更改你的 git 配置，包括你的用戶名。

下面用一個例子來解釋。

假設你要提供用戶名和電子郵件 ID 用來將提交與身份相關聯，以便你能夠知道是誰進行了特定提交。爲此，我將使用：

git config –global user.name "Your Name": 此命令將添加用戶名。

git config –global user.email "Your E-mail Address": 此命令將添加電子郵件ID。

Q13. 提交對象包含什麼？

Commit 對象包含如下組件，你應該提到如下這三點：

一組文件，表示給定時間點的項目狀態
引用父提交對象
SHAI 名稱，一個40個字符的字符串，提交對象的惟一標識。
Q14. 如何在Git中建立存儲庫？

這多是最多見的問題，答案很簡單。

要建立存儲庫，先爲項目建立一個目錄（若是該目錄不存在），而後運行命令 git init。經過運行此命令，將在項目的目錄中建立 .git 目錄。

Q15. 怎樣將 N 次提交壓縮成一次提交？

將N個提交壓縮到單個提交中有兩種方式：

若是要從頭開始編寫新的提交消息，請使用如下命令：

1git reset –soft HEAD~N &&
2git commit

若是你想在新的提交消息中串聯現有的提交消息，那麼須要提取這些消息並將它們傳給 git commit，能夠這樣：

1git reset –soft HEAD~N &&
2git commit –edit -m"$(git log –format=%B –reverse .HEAD@{N})"

Q16. 什麼是 Git bisect？如何使用它來肯定（迴歸）錯誤的來源？

我建議你先給出一個Git bisect 的小定義。

Git bisect 用於查找使用二進制搜索引入錯誤的提交。 Git bisect的命令是

1git bisect <subcommand> <options>

既然你已經提到過上面的命令，那就解釋一下這個命令會作什麼。

此命令用了二進制搜索算法來查找項目歷史記錄中的哪一個提交引入了錯誤。你能夠經過告訴它已知包含該錯誤的「錯誤」提交以及在引入錯誤以前已知的「良好」提交來使用它。而後 git bisect 在這兩個端點之間選擇一個提交，並詢問你所選的提交是「好」仍是「壞」。它繼續縮小範圍，直到找到引入更改的確切提交。

Q17. 若是想要在提交以前運行代碼性檢查工具，並在測試失敗時阻止提交，該怎樣配置 Git 存儲庫？

我建議你先介紹一下完整性檢查。

完整性或冒煙測試用來肯定繼續測試是否可行和合理。

下面解釋如何實現這一目標。

這能夠經過與存儲庫的 pre-commit hook 相關的簡單腳原本完成。git 會在提交以前觸發 pre-commit hook。你能夠在這個腳本中運行其餘工具，例如 linters，並對提交到存儲庫中的更改執行完整性檢查。

最後舉個例子，你能夠參考下面的腳本：

1#!/bin/sh
 2files=$(git diff –cached –name-only –diff-filter=ACM | grep ‘.go$’)
 3if [ -z files ]; then
 4    exit 0
 5fi
 6unfmtd=$(gofmt -l $files)
 7if [ -z unfmtd ]; then
 8    exit 0
 9fi
10echo 「Some .go files are not fmt’d」
11exit 1

這段腳本檢查是否須要經過標準 Go 源代碼格式化工具 gofmt 傳遞全部即將提交的 .go 文件。若是腳步以非 0 狀態退出，腳本會有效地阻止提交操做。

Q18. 描述一下你所使用的分支策略？

這個問題被要求用Git來測試你的分支經驗，告訴他們你在之前的工做中如何使用分支以及它的用途是什麼，你能夠參考如下提到的要點：

功能分支（Feature branching）

要素分支模型將特定要素的全部更改保留在分支內。當經過自動化測試對功能進行全面測試和驗證時，該分支將合併到主服務器中。

任務分支（Task branching）

在此模型中，每一個任務都在其本身的分支上實現，任務鍵包含在分支名稱中。很容易看出哪一個代碼實現了哪一個任務，只需在分支名稱中查找任務鍵。

發佈分支（Release branching）

一旦開發分支得到了足夠的發佈功能，你就能夠克隆該分支來造成發佈分支。建立該分支將會啓動下一個發佈週期，因此在此以後不能再添加任何新功能，只有錯誤修復，文檔生成和其餘面向發佈的任務應該包含在此分支中。一旦準備好發佈，該版本將合併到主服務器並標記版本號。此外，它還應該再將自發布以來已經取得的進展合併回開發分支。

最後告訴他們分支策略因團隊而異，因此我知道基本的分支操做，如刪除、合併、檢查分支等。

Q19. 若是分支是否已合併爲master，你能夠經過什麼手段知道？

答案很直接。

要知道某個分支是否已合併爲master，你可使用如下命令：

git branch –merged 它列出了已合併到當前分支的分支。

git branch –no-merged 它列出了還沒有合併的分支。

Q20. 什麼是SubGit？

SubGit 是將 SVN 到 Git遷移的工具。它建立了一個可寫的本地或遠程 Subversion 存儲庫的 Git 鏡像，而且只要你願意，能夠隨意使用 Subversion 和 Git。

這樣作有不少優勢，好比你能夠從 Subversion 快速一次性導入到 Git 或者在 Atlassian Bitbucket Server 中使用SubGit。咱們能夠用 SubGit 建立現有 Subversion 存儲庫的雙向 Git-SVN 鏡像。你能夠在方便時 push 到 Git 或提交 Subversion。同步由 SubGit 完成。

原文：https://www.edureka.co/blog/interview-questions/git-interview-questions/