編輯

共用方式為


Git 常見問題

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

在本文中,尋找 Git 常見問題的解答,專為 Azure Repos 量身打造。 無論您是想要管理遠端分支、識別最新分支,或處理其他較不常見的 Git 工作,本指南都提供實用的秘訣和解決方案。 深入瞭解下列各節,以增強 Git 工作流程並解決常見問題。

如何輕鬆地將遠端分支下載到本機存放庫?

首先,請確定您已設定存放 origin 庫。 如果您使用 複製存放庫 git clone,您應該擁有此專案。 當您在本機簽出不存在的分支時,Git 會檢查是否有具有相同名稱的遠端分支。 如果有的話,Git 會建立參考遠端分支的本機分支。 使用 git pull 下載認可,並在本機更新分支歷程記錄。

如何找出我在哪個分支工作?

執行 git branch 時沒有自變數,以顯示本機分支,並反白顯示您已取出的分支。在 Visual Studio 中,當您使用儲存在本機 Git 存放庫中的專案時,狀態列也會顯示最新分支。

何時應該進行 Git 認可?

最佳做法是針對邏輯上不同的變更進行個別認可。 請將認可視為記錄簿中的專案。 每當您進行值得指出的變更時,請將其記錄在認可中。 常見的方法是允許頻繁的本機認可,但在推送之前,先透過 重新處理 來壓倒它們。 這可提供彈性,同時保持認可歷程記錄的簡化。

如果每個分支都保留其完整認可歷程記錄,那不會讓 *main* 的認可歷程記錄隨著時間而難以追蹤嗎?

具有許多認可和參與者的大型專案可能會導致 main 分支歷程記錄,以反映主題分支的開發,而不是整體專案。 Git 可讓您透過 壓縮認可和重設大小來壓縮分支上的認可。 壓縮認可可讓分支歷程記錄變得不那麼詳細,在合併后簡化主要分支上的認可歷程記錄。

如何找出誰對檔案進行特定變更?

git blame使用 命令來找出對檔案進行特定變更的人員。 從本機存放庫,您可以使用 參數來執行git blame-L,並指定感興趣的行。 Blame 會產生格式化輸出,其中顯示上次更新該行的認可,以及進行認可的人員名稱。

> git blame Example_repo -L 20,+40  # show the blame output for the next 40 lines starting at line 20

215d1108 (Example User 2015-11-21 09:54:23 -0800 20) line 20 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 21) line 21 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 22) line 22 of the code

Blame 會為您搜尋認可歷程記錄。 您也可以在入口網站中檢閱檔案的歷程記錄,以判斷誰進行了變更和何時進行變更。 開啟存放庫和分支的程式代碼總管,然後選取感興趣的檔案。 Azure Repos 會顯示最新分支上該檔案的完整認可歷程記錄。

我對某些檔案進行了變更,現在我無法簽出不同的分支或重新設定工作基底。

簽出 Git 中的不同分支會影響文件系統上的檔案狀態。 Git 會使用認可歷程記錄,以確定您正在使用代表分支狀態的檔案。 如果您在未認可變更時嘗試變更分支,則在簽出期間會覆寫這些變更。 因為 Git 不希望您不小心遺失變更,所以可防止簽出發生。 您有兩個選擇:

  • 放棄變更並返回最新的認可。 如需如何回復至最新認可的指示,請參閱 Git 中的復原變更。
  • 認可變更。 請參閱 使用認可將工作儲存在 Git 中。
  • 隱藏 您目前的工作,儲存變更以供稍後使用,並將工作區清除為最後一個認可。

提取要求無法與這個訊息合併:「無法自動合併:其中一個內部 git 物件(Blob、樹狀結構、認可或標記)太大,造成TF401022例外狀況。 您可以嘗試使用 LFS,將您的合併或大型認可分割成數個小。

此問題與大型二進位檔中的合併衝突有關。 檔案目前的限制為 100MB。 因應措施是將目標合併到本機來源、解決衝突,以及推送變更,以在本機解決合併衝突。

建議使用 Git LFS (大型檔案記憶體)來儲存大型二進位檔,不僅要避免衝突,還能管理影響複製和推送時間的整體存放庫大小。

我做了一些工作, 但需要切換到別的東西。 如何在不認可變更的情況下儲存工作以供稍後使用?

如果您要儲存變更而不認可變更,請使用 Git stash。 Stash 會儲存分支中目前暫存和未標記的變更,並將分支還原為上次認可的狀態。 然後,您可以切換至另一個分支、執行您的工作,稍後再執行 stash apply 以還原變更。

git stash
Saved working directory and index state WIP on feature1: be26067 updated endpoint docs
HEAD is now at be26067

當您執行 [git stash apply]時,最近隱藏的變更會套用至最新分支。 如果發生衝突,[stash] 會還原不衝突之檔案的變更,並在所執行的檔案中建立衝突標記。 在此情況下,您應該手動合併變更。

完成隱藏之後,請使用 [git stash drop] 將其刪除。 此命令會移除最後一組隱藏的變更。

您可以有多個隱藏,但管理它們需要更多手動操作,因為您必須明確套用和卸除隱藏。 請從 Git Stash 檔深入瞭解。

如何變更 Git 命令列工具的預設編輯器?

根據預設,命令行 Git 會在要求認可訊息、執行重新基底和其他需要其他資訊才能完成的工作時,使用命令行編輯器。 預設編輯器是使用 git config來設定:

> git config core.editor _path_to_editor_ _options_to_editor_

Git For Windows 可讓您輕鬆地將記事本設定為編輯器:

> git config core.editor notepad

此命令會將 Windows 記事本設定為視需要編輯 Git 資訊,並正確地將文字從 Git 傳遞至記事本。 您也可以指定

> git config format.commitMessageColumns 72 

若要將認可訊息中的文字數據行保留在慣用的 72 和行換行之後,達到該行的字元限制。

如何變更認可中顯示的使用者名稱和電子郵件?

Git 會將使用者名稱和電子郵件地址資訊放在每個認可內,而 Azure Repos 會在檢視認可和使用提取要求時使用此資訊。 如果您正在使用命令列,您可以使用 命令來更新顯示 git config 的名稱和電子郵件資訊:

> git config --global user.email "example-user@example-site.com"
> git config --global user.name "Example User"

選項 --global 會設定此系統上所有 Git 存放庫認可中包含的電子郵件和名稱。 如果您想要變更單一存放庫的設定,您必須變更為 Git 存放庫所在的目錄,並在不使用 旗標的情況下 --global 執行上述命令。

您也可以從 Visual Studio 變更名稱和電子郵件設定。 從 [Git] 功能表中,選取 [選項] 對話方塊中的 [設定],選取 [Git 全域設定] 或 [Git 存放庫設定>一般]。

Visual Studio 2019 16.8 版和更新版本提供 Git 版本控制體驗,同時維護 Team Explorer Git 使用者介面。 若要使用Team Explorer,請從功能表列取消核取 [工具>選項>預覽功能>] [新增 Git 使用者體驗]。 您可以從任一接換練習 Git 功能。

在 Team Explorer 中,選擇 [設定],然後在 [Git] 下選取 [全域設定] 或 [存放庫設定] 連結。