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列出尚未合并的分支,
歡迎關注 Java架構師社區公眾號.
本文轉載自Java架構師必看 ,更多內容點擊查看!
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/178577.html
標籤:Java
上一篇:c/c++ 程式設計初步(一)(小白必學知識點以及復習總結專用)
下一篇:19。洗掉鏈表倒數第N個節點
