自從我使用 git/github 已經有一分鐘了，事情似乎發生了一些變化。
我在 GitHub 上設定了一個新的 repo（使用readme），然后在我的計算機上創建了一個匹配的目錄，我將使用它。
在該匹配目錄中打開終端...
git init
git remote add origin https://github.com/(username)/(reponame).git
git pull origin main
我收到了關于...的警告
"Pulling without specifying how to reconcile divergent branches is discouraged."
但除此之外，拉動作業正常，自述檔案現在在我的本地目錄中。
顯然我在命令中有正確的“用戶名”和“reponame”。
但是為了確保一切順利，我修改了自述檔案并嘗試將其推送到存盤庫...
git add -A
git commit -m "First commit, updating readme"
git push origin main
并收到錯誤：
error: src refspec main does not match any
error: failed to push some refs to 'https://github.com/(username)/(reponame).git'
看網上的repo，只有一個分支：main
當我檢查時在終端...
git show-ref
我得到兩個輸出......
5...(redacted)...e refs/heads/master
c...(redacted)...0 refs/remotes/origin/main
如果我嘗試命令
push origin master
沒有錯誤，但它在 repo 上創建了一個單獨的分支。
所以，不用說，我完全迷失了，不知道發生了什么。
感謝您的任何建議。
uj5u.com熱心網友回復：
TL;博士：git branch -m main
對于您的具體情況，修復很簡單：只需將您的本地分支重命名master為main，然后您就可以從這里開始使用新奇的名稱。閱讀其余部分是可選的，但應該可以幫助您避免未來的障礙。
發生了什么（長且可選）
這個序列：
mkdir (new-directory); cd (new-directory) git init git remote add origin https://github.com/(username)/(reponame).git git pull origin main
在功能上沒有錯，但不是你通常應該做的；通常你只想：
git clone https://github.com/(username)/(reponame).git (new-directory)
cd (new directory)
new-directory如果您要創建的目錄名稱與reponame: Git 將剝離.git并使用它，則可以省略該名稱。該git clone命令執行mkdir并運行新目錄中的其余命令：
- [為 mkdir 步驟保留，如果您提供一個空目錄供
git clone使用，則跳過該步驟] git init[在由步驟 1 創建或提供的新目錄中運行]git remote add origin url[使用您提供的網址]- [保留用于額外
git config步驟，如果您使用-c選項] git fetch origin（不是git pull！）git switch branch，branch您的-b選擇在哪里。
這六步程序就是真正的意義git clone所在。該git init步驟在該空目錄中創建新的空存盤庫資料庫，并創建一個隱藏.git目錄來保存它們。該git remote add步驟保存您的 URL 以供將來使用，第 5 步，即git fetch讓您的 Git 軟體呼叫 Git 軟體，該軟體在保存的 URL 處進行回應并復制該存盤庫中的所有提交。
在這個程序中的這一點——在第 5 步結束時——你有他們的所有提交并且根本沒有分支。該git fetch步驟確實看到了他們所有的分支名稱，但在您的資料庫中創建了遠程跟蹤名稱，而不是創建分支名稱。這對Git來說很好，因為 Git 可以在沒有任何分支名稱的情況下作業，但對于喜歡分支名稱的人類來說不是很好。所以我們繼續進行第 6 步，a git checkoutorgit switch會創建一個分支名稱。
第 6 步創建的分支名稱將與克隆存盤庫具有的某個分支名稱拼寫相同。如果它們（origin存盤庫）有多個分支名稱，您可以使用該選項選擇哪一個-b。不過，大多數人有時不會為這個-b選項而煩惱git clone。在這種情況下，您的 Git 軟體會詢問他們的 Git 軟體其他存盤庫推薦的名稱。
GitHub 為您提供了一種設定方法，每個 GitHub 存盤庫。GitHub 和 Git 一樣，將其稱為默認分支。在過去，這默認master為新創建的 GitHub 存盤庫的名稱，但現在默認為 name main。因為人們不-b為他們的命令提供選項git clone，所以有時知道某個 GitHub 存盤庫將使用哪個名稱作為其“默認分支”設定很重要。這是他們要推薦的名稱，由于 Git 中的一個小缺陷，即使該分支名稱不存在，他們也會推薦該分支名稱。
空的 Git 存盤庫困境
一個 Git存盤庫——與一個簽出的作業樹不同，它包含你可以處理/使用的普通檔案——它的核心只是兩個資料庫。
一個，通常更大，包含 Git 的提交物件和其他支持物件。這些存盤提交，這是存盤庫中的歷史記錄。每個提交，由一個物件 ID (OID) 或更通俗地說，一個哈希 ID找到，存盤每個檔案的完整快照，并按照您或任何人提交提交時的形式及時凍結；每個提交還存盤一些元資料，或有關該特定提交的資訊。這些資訊結合起來將提交相互鏈接。
第二個單獨的資料庫保存名稱：分支名稱、標簽名稱和所有其他形式的名稱。每個名稱僅存盤一個 OID（哈希 ID），特別是分支名稱始終存盤提交哈希 ID。這些存盤的哈希 ID 隨著時間的推移而演變。
根據定義，存盤在任何給定分支名稱中的哈希 ID是被視為“在分支上”的最后一次提交。然后，進行新的提交包括進行其父提交是當前最后一個提交的提交，然后更改該分支名稱中存盤的哈希 ID以保存新提交的新哈希 ID。
這些定義意味著，如果我們根本沒有提交，就沒有哈希 ID，因此也不會有任何分支名稱。分支名稱必須包含某個現有提交的哈希 ID。沒有提交，就沒有這樣的哈希 ID。
盡管如此，要使用Git——能夠創建檔案git add然后運行——我們必須“在”某個分支上。因此，當我們運行它并創建了一個新的、完全空的資料庫對時，我們遇到了一個難題：不能有任何分支，但我們必須“在”某個分支上。git commitgit init
Git以 Alexander 所認為的方式解決了這個Gordian 結，只需將其砍成碎片即可。Git 規定當前分支名稱——當我們在 Git 存盤庫中作業時我們“打開”的分支——是存盤在特殊名稱中的名稱HEAD，并且HEAD可以包含不存在的分支的名稱。
所以在 之后git init，我們“打開”了一個不存在的分支！當我們進行第一次提交時，該分支就會出現。我們所做的提交是根提交——沒有父提交的提交，這在幾個方面都很特殊——新提交與任何新提交一樣，都會獲得一個新的、唯一的哈希 ID。現在物件資料庫中有一個提交，有一個有效的哈希 ID 存盤在分支名稱中，所以 Git 現在在名稱資料庫中創建分支名稱，將該哈希 ID 存盤到該資料庫中的名稱中。
GitHub 在這一切中的作用
當您使用他們的 Web 界面在GitHub 上創建一個新存盤庫時，GitHub 讓您有機會創建一個包含初始的、有些特殊的根提交的存盤庫。這消除了困境：現在有一個提交，所以可以有一個分支名稱。這也意味著您可以擁有一些初始檔案，例如 README 和/或許可證和/或著作權和/或初始.gitignore檔案：您可以放入任何您喜歡的檔案（前提是 GitHub 為您提供了包含它們的模板）。
如果您愿意，您可以創建一個完全空的 GitHub 存盤庫。當您這樣做時，他們現在將推薦的（“默認”）分支名稱設定為main. 他們過去常常將其設定為master, 在過去。 確保創建此分支由您決定！
（我懷疑大多數人都會接受“為我進行初始提交”的提議，但我沒有這方面的實際統計資料。他們——GitHub——必須進行統計分析。）
你做了什么
你：
- 讓 GitHub 創建一個帶有初始提交的存盤庫，該存盤庫具有一些哈希 ID，它們存盤在名稱下
refs/heads/main：分支main； - 創建了您自己的完全空的存盤庫，沒有提交，位于 Git 自己的默認初始分支
master（全名refs/heads/master）上；進而 - 跑了
git pull origin main。
該git pull命令主要是運行其他兩個Git 命令的便捷簡寫：
git fetch，它獲取您傳遞給的大部分選項和引數git pull；進而- 第二個 Git 命令：其中一個
git merge或git rebase，帶有一些毛茸茸的特殊外殼，用于“拉入一個空的存盤庫”。1
在git fetch您的情況下， 獲取您在 GitHub 上所做的初始提交，在他們的分支名稱下main，在您的存盤庫中創建origin/main為遠程跟蹤名稱。請注意，此時您仍然沒有分支名稱！
現在你的 Git 運行了第二個命令。在你的情況下，這是git merge. 這是git pull產生警告的地方：
"Pulling without specifying how to reconcile divergent branches is discouraged."
這個警告有點奇怪，因為此時您沒有“發散分支”。事實上，你根本沒有任何分支！但這是特殊情況處理的開始。你所在的不存在的分支，master沒有提交，與現有的單提交“分支” 2 “分歧”，后者的第一個、最后一個也是唯一的提交是現在origin/main在您的存盤庫中的名稱下列出。
盡管如此，git merge能夠將他們的main-your origin/main- 與您的master. 這創建了您的分支名稱master，標識了與他們的分支名稱相同的提交- 您的.mainorigin/main
如果我們在您的存盤庫中繪制提交，我們只有一個提交，您參考為c...(redacted)...0. origin/main您的 Git 使用名稱—really找到這個提交refs/remotes/origin/main，這是它的全名，但人類通常會縮短這些提交，Git 有時會這樣做，具體取決于您使用的 Git 命令。
因為特殊情況的代碼現在可以作業了（至少從 Git 1.7 開始），這并沒有破壞任何作業，而是從你現在擁有的一個提交中簽出檔案。現在你有你的分支，命名為master，標識與“他們的”（你的 GitHub 存盤庫的）分支相同的提交，main在 GitHub 存盤庫中命名。
從這里開始，事情就很簡單了：您修改了README檔案，添加并提交了。這產生了一個新的提交，5...(redacted)...e其父提交是初始提交，并將新提交的名稱存盤在您的名稱資料庫中的名稱master( ) 中。refs/heads/master
1這個特殊的外殼在早期的 Git 版本（1.5.something，甚至可能是 1.6.something）中被破壞了，我至少被嚴重燒傷了一次。這就是我開始避免的原因之一git pull——結果證明這是一件好事，因為通過單獨的 fetch 和 second-command 序列，人們可以了解 Git 的作業原理！
2我在這里把“分支”這個詞加了引號，因為origin/main它不是一個分支名稱，它是一個遠程跟蹤名稱。它是一個“分支”嗎？這取決于我們說“分支”時的意思：“分支”到底是什么意思？
修復
如果您現在重命名您的名稱master來呼叫它main：
git branch -m main
你最終得到：
A <-- origin/main
\
B <-- main (HEAD)
其中字母A代表初始提交的哈希 ID，并B代表您的新提交5...(redacted)...e。CommitB的父級是A，因此您可以git push origin main將提交發送B 到您的 GitHub 存盤庫，他們會將其添加到他們 main的 GitHub 存盤庫中，以便您的 Git 更新您的origin/mainnames資料庫：
A--B <-- main (HEAD), origin/main
一切都很好。
你也可以在任何時候——在推送之前或之后——將你的分支名稱的上游main設定——現在因為你的git branch -m命令——設定為字串origin/main。3 您可以使用單獨的git branch --set-upstream-to命令執行此操作，甚至可以與您的git pushas一起執行此操作git push -u origin main。
3git branch --set-upstream-to命令和類似的命令使用這樣的字串。但是，由于歷史原因，檔案中的配置分為兩.git/config部分：遠程和分支。這里的映射很復雜，但如果你使用所有默認值，4似乎很origin簡單：我們只需將遠程名稱, 加上分支名稱-as-seen-on-the-remote,串在一起main即可得到origin/main。
4這里沒有理由不使用默認值。但是，如果您奇怪地設定了獲取映射，origin/funky即使他們呼叫它，您也可以將其用作遠程跟蹤名稱main。然后，您可以呼叫您的（本地）分支winkerbean，例如。這將存盤在您的.git/configasbranch.winkerbean.remote = origin和branch.winkerbean.merge = main中，即使分支的“上游”winkerbean現在是origin/funky并向git branch -r您顯示origin/funkyorigin 的main. 不要這樣做，你只會讓自己發瘋。 但它實際上所有的作業。
設定你的 Git 以git init使用main
如果你喜歡新世界main而不是master，或者只是不夠固執（或其他）堅持生活在過去，5你可以設定你的 Git，這樣當你運行時git init，它會把你放在不存在的分支上namemain而不是不存在的分支名稱master。不過，這需要一個足夠新的 Git，或者一個小技巧。
在 Git 2.28 及更高版本中，您可以運行：
git config --global init.defaultBranch main
一切就緒。但是，如果您的 Git早于2.28 版，則您沒有init.defaultBranch（我認為您也沒有--initial-branch=）。在這里，您可以使用一個簡單的技巧。當git init創建一個新的空存盤庫時，您將處于打開狀態master，但您可以使用以下命令更改這個不存在的分支的名稱git checkout --orphan：6
git checkout --orphan main
或者，進行第一次提交——至少在這些舊版本的 Git 中，這是必需的——然后運行：
git branch -m main
重命名master創建的git commit。
5但過去是那么舒服！ 這一切都帶著懷舊的朦朧和...... ?難道這一切都那么簡單嗎？還是時間重寫了每一行？?不，等等，過去，現在，未來，這一切都很可怕。最好不要出生。但是我們當中誰有這樣的運氣呢？也許百萬分之一。——阿爾弗雷德·波爾加
6你也可以這樣做git switch --orphan，但如果你的 Git 早于 2.28，也許它早于 2.23，你也沒有新奇git switch的。請注意，git switch --orphan清空 Git 的索引，而git checkout --orphan不會，盡管對于這種情況，這通常無關緊要。
uj5u.com熱心網友回復：
我不確定，但在這種情況下，您的本地master（在我看來，您的本地分支被稱為master，而不是main）可能無法跟蹤您的遠程main。嘗試這樣做：結帳到您當地master，然后git branch -u origin/main
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/470876.html