Java的Git面試題有哪些

本篇內(nèi)容主要講解“Java的Git面試題有哪些”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“Java的Git面試題有哪些”吧!

問(wèn)題一：什么是 Git 復(fù)刻（fork）？復(fù)刻（fork）、分支（branch）和克?。╟lone）之間有什么區(qū)別？

復(fù)刻（fork） 是對(duì)存儲(chǔ)倉(cāng)庫(kù)（repository）進(jìn)行的遠(yuǎn)程的、服務(wù)器端的拷貝，從源頭上就有所區(qū)別。復(fù)刻實(shí)際上不是 Git 的范疇。它更像是個(gè)政治/社會(huì)概念。

克?。╟lone） 不是復(fù)刻，克隆是個(gè)對(duì)某個(gè)遠(yuǎn)程倉(cāng)庫(kù)的本地拷貝。克隆時(shí)，實(shí)際上是拷貝整個(gè)源存儲(chǔ)倉(cāng)庫(kù)，包括所有歷史記錄和分支。

分支（branch） 是一種機(jī)制，用于處理單一存儲(chǔ)倉(cāng)庫(kù)中的變更，并最終目的是用于與其他部分代碼合并。

問(wèn)題二：“拉取請(qǐng)求（pull request）”和“分支（branch）”之間有什么區(qū)別？

分支（branch） 是代碼的一個(gè)獨(dú)立版本。

拉取請(qǐng)求（pull request） 是當(dāng)有人用倉(cāng)庫(kù)，建立了自己的分支，做了些修改并合并到該分支（把自己修改應(yīng)用到別人的代碼倉(cāng)庫(kù)）。

問(wèn)題三：“git pull”和“git fetch”之間有什么區(qū)別？

簡(jiǎn)單來(lái)說(shuō)，git pull 是 git fetch + git merge。

當(dāng)你使用 pull，Git 會(huì)試著自動(dòng)為你完成工作。它是上下文（工作環(huán)境）敏感的，所以 Git 會(huì)把所有拉取的提交合并到你當(dāng)前處理的分支中。pull 則是 自動(dòng)合并提交而沒(méi)有讓你復(fù)查的過(guò)程。如果你沒(méi)有細(xì)心管理你的分支，你可能會(huì)頻繁遇到?jīng)_突。

當(dāng)你 fetch，Git 會(huì)收集目標(biāo)分支中的所有不存在的提交，并將這些提交存儲(chǔ)到本地倉(cāng)庫(kù)中。但Git 不會(huì)把這些提交合并到當(dāng)前分支中。這種處理邏輯在當(dāng)你需要保持倉(cāng)庫(kù)更新，在更新文件時(shí)又希望處理可能中斷的事情時(shí)，這將非常實(shí)用。而將提交合并到主分支中，則該使用 merge。

問(wèn)題四: 解釋 Forking 工作流程的優(yōu)點(diǎn)

Forking 工作流程 與其他流行的 Git 工作流程有著根本的區(qū)別。它不是用單個(gè)服務(wù)端倉(cāng)庫(kù)充當(dāng)“中央”代碼庫(kù)，而是為每個(gè)開(kāi)發(fā)者提供自己的服務(wù)端倉(cāng)庫(kù)。Forking 工作流程最常用于公共開(kāi)源項(xiàng)目中。

Forking 工作流程的主要優(yōu)點(diǎn)是可以匯集提交貢獻(xiàn)，又無(wú)需每個(gè)開(kāi)發(fā)者提交到一個(gè)中央倉(cāng)庫(kù)中，從而實(shí)現(xiàn)干凈的項(xiàng)目歷史記錄。開(kāi)發(fā)者可以推送（push）代碼到自己的服務(wù)端倉(cāng)庫(kù)，而只有項(xiàng)目維護(hù)人員才能直接推送（push）代碼到官方倉(cāng)庫(kù)中。

當(dāng)開(kāi)發(fā)者準(zhǔn)備發(fā)布本地提交時(shí)，他們的提交會(huì)推送到自己的公共倉(cāng)庫(kù)中，而不是官方倉(cāng)庫(kù)。然后他們向主倉(cāng)庫(kù)提交請(qǐng)求拉?。╬ull request），這會(huì)告知項(xiàng)目維護(hù)人員有可以集成的更新。

問(wèn)題五: 告訴我 Git 中 HEAD、工作樹(shù)和索引之間的區(qū)別？

該工作樹(shù)/工作目錄/工作空間是你看到和編輯的（源）文件的目錄樹(shù)。

該索引/中轉(zhuǎn)區(qū)（staging area）是個(gè)在 /.git/index，單一的、龐大的二進(jìn)制文件，該文件列出了當(dāng)前分支中所有文件的 SHA1 檢驗(yàn)和、時(shí)間戳和文件名，它不是個(gè)帶有文件副本的目錄。

HEAD是當(dāng)前檢出分支的最后一次提交的引用/指針。

問(wèn)題六：你能解釋下 Gitflow 工作流程嗎？

Gitflow 工作流程使用兩個(gè)并行的、長(zhǎng)期運(yùn)行的分支來(lái)記錄項(xiàng)目的歷史記錄，分別是 master 和 develop 分支。

Master，隨時(shí)準(zhǔn)備發(fā)布線上版本的分支，其所有內(nèi)容都是經(jīng)過(guò)全面測(cè)試和核準(zhǔn)的（生產(chǎn)就緒）。

Hotfix，維護(hù)（maintenance）或修復(fù)（hotfix）分支是用于給快速給生產(chǎn)版本修復(fù)打補(bǔ)丁的。修復(fù)（hotfix）分支很像發(fā)布（release）分支和功能（feature）分支，除非它們是基于 master 而不是 develop 分支。

Develop，是合并所有功能（feature）分支，并執(zhí)行所有測(cè)試的分支。只有當(dāng)所有內(nèi)容都經(jīng)過(guò)徹底檢查和修復(fù)后，才能合并到 master 分支。

Feature，每個(gè)功能都應(yīng)留在自己的分支中開(kāi)發(fā)，可以推送到 develop 分支作為功能（feature）分支的父分支。

問(wèn)題七: 什么時(shí)候應(yīng)使用 “git stash”？

git stash 命令把你未提交的修改（已暫存（staged）和未暫存的（unstaged））保存以供后續(xù)使用，以后就可以從工作副本中進(jìn)行還原。

回顧：

$ git status

On branch master

Changes to be committed:

new file: style.css

Changes not staged for commit:

modified: index.html

$ git stash

Saved working directory and index state WIP on master: 5002d47 our new homepage

HEAD is now at 5002d47 our new homepage

$ git status

On branch master

nothing to commit, working tree clean

我們可以使用暫存（stash）的一個(gè)地方是，如果我們發(fā)現(xiàn)在上次提交中忘記了某些內(nèi)容，并且已經(jīng)開(kāi)始在同一分支中處理下一個(gè)提交了：

# Assume the latest commit was already done

# start working on the next patch, and discovered I was missing something

# stash away the current mess I made

$ git stash save

# some changes in the working dir

# and now add them to the last commit:

$ git add -u

$ git commit --ammend

# back to work!

$ git stash pop

問(wèn)題八: 如何從 git 中刪除文件，而不將其從文件系統(tǒng)中刪除？

如果你在 git add 過(guò)程中誤操作，你最終會(huì)添加不想提交的文件。但是，git rm 則會(huì)把你的文件從你暫存區(qū)（索引）和文件系統(tǒng)（工作樹(shù)）中刪除，這可能不是你想要的。換成 git reset 操作：

git reset filename # or

echo filename >> .gitingore # add it to .gitignore to avoid re-adding it

上面意思是，git reset <paths> 是 git add <paths> 的逆操作。

問(wèn)題十: 是么時(shí)候使用“git rebase”代替“git merge”？

這兩個(gè)命令都是把修改從一個(gè)分支集成到另一個(gè)分支上，它們只是以非常不同的方式進(jìn)行?？紤]一下場(chǎng)景，在合并和變基前：

A <- B <- C [master]

^

\

D <- E [branch]

在 git merge master 之后：

A <- B <- C

^ ^

\ \

D <- E <- F

在 git rebase master 之后：

A <- B <- C <- D <- E

使用變基時(shí)，意味著使用另一個(gè)分支作為集成修改的新基礎(chǔ)。

何時(shí)使用：

如果你對(duì)修改不夠果斷，請(qǐng)使用合并操作。

根據(jù)你希望的歷史記錄的樣子，而選擇使用變基或合并操作。

更多需要考慮的因素：

1、分支是否與團(tuán)隊(duì)外部的開(kāi)發(fā)人員共享修改（如開(kāi)源、公開(kāi)項(xiàng)目）？如果是這樣，請(qǐng)不要使用變基操作。變基會(huì)破壞分支，除非他們使用 git pull --rebase，否則這些開(kāi)發(fā)人員將會(huì)得到損壞的或不一致的倉(cāng)庫(kù)。

2、你的開(kāi)發(fā)團(tuán)隊(duì)技術(shù)是否足夠嫻熟？變基是一種破壞性操作。這意味著，如果你沒(méi)有正確使用它，你可能會(huì)丟失提交，并且/或者會(huì)破壞其他開(kāi)發(fā)者倉(cāng)庫(kù)的一致性。

3、分支本身是否代表有用的信息？一些團(tuán)隊(duì)使用功能分支（branch-per-feature）模式，每個(gè)分支代表一個(gè)功能（或錯(cuò)誤修復(fù)，或子功能等）。在此模式中，分支有助于識(shí)別相關(guān)提交的集合。在每個(gè)開(kāi)發(fā)人員分支（branch-per-developer）模式中，分支本身不會(huì)傳達(dá)任何其他信息（提交信息已有作者）。則在這種模式下，變基不會(huì)有任何破壞。

4、是否無(wú)論如何都要還原合并？恢復(fù)（如在撤銷(xiāo)中）變基，是相當(dāng)困難的，并且/或者在變基中存在沖突時(shí)，是不可能完成的。如果你考慮到日后可能需要恢復(fù)，請(qǐng)使用合并操作。

到此，相信大家對(duì)“Java的Git面試題有哪些”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！