將遠程存儲庫和遠程分支作為簽出的參數是什么意思？

Question

我看到無法創建文件的git命令...權限被拒絕

git checkout origin develop

我只知道結帳當地分支機構。 將遠程存儲庫和遠程分支作為簽出的參數是什么意思？ 我在https://git-scm.com/docs/git-checkout中找不到

Answer 1

命令git checkout origin develop意思是“從名為origin的分支（ 分支 ，不是遠程！）中git checkout origin develop名為develop文件（ 文件 ，不是分支！）”。 如果您具有分支origin ，並且分支指向包含文件develop的提交，則命令成功。

但是您可能都沒有，所以該命令實際上沒有任何意義。 StackOverflow充滿了錯誤的問題和錯誤的答案； 不要相信你看到的一切。

這里有意義的命令可以是git checkout origin/develop ，這意味着“檢出由名為origin/develop的遠程跟蹤參考指向的提交”。

這里的另一個有意義的命令可能是git checkout develop ，這意味着“創建一個名為新的本地分支develop從遠程跟蹤參考分支它命名為origin/develop ;設置跟蹤，使得遠程跟蹤參考命名origin/develop成為本地上游分支名為“ develop ”的分支。

請參閱https://git-scm.com/docs/git-checkout上的git checkout文檔

Answer 2

TL; DR

你不必兩者的存儲庫，這里的一個分支。 相反，您具有樹狀結構和pathspec 。 tree-ish是一個提交說明符origin ，它是origin/HEAD縮寫，它是...的縮寫，很好，請參見下文。 pathspec是develop ，這僅表示名為develop的文件 。 如果沒有這樣的文件，該命令將簡單地失敗。

Long：如何閱讀Git文檔

git checkout的語法是 ：

1. git checkout [-q] [-f] [-m] [<branch>]
2. git checkout [-q] [-f] [-m] --detach [<branch>]
3. git checkout [-q] [-f] [-m] [--detach] <commit>
4. git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
5. git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
6. git checkout [<tree-ish>] [--] <pathspec>...
7. git checkout (-p|--patch) [<tree-ish>] [--] [<paths>...]

這些都不允許您兩次指定分支名稱。

嘗試匹配：

git checkout origin develop

以上七個可能的語法行。 它與＃1不匹配，后者僅允許一個<branch>參數，而沒有其他參數。 它與＃2不匹配，后者需要一個文字--detach 。 它與＃3不匹配，后者僅允許一個<commit>參數，而沒有常規參數。 它與＃4不匹配，后者僅允許一個可選的<start-point>參數，並且與＃7不匹配，后者需要一個文字-p或--patch 。

它確實匹配＃5和＃6。 這些可能不應該是兩個單獨的語法行，而在隨后的描述部分中 ，它們不是—只是其中一個部分：

git checkout [<tree-ish>] -- [<pathspec> ...]

它的缺點是在簡短的摘要中沒有提及所有可選標志，但隨后在正文中提及了這些標志：

通過替換索引或<tree-ish>中的內容（通常是提交）來覆蓋工作樹中的路徑。 給定<tree-ish>時，與<pathspec>匹配的路徑會同時在索引和工作樹中更新。

由於先前的合並失敗，索引可能包含未合並的條目。 默認情況下... [ --ours這是提及-f和--ours等標志的地方]

現在，此文本充滿了Git行話，尤其是tree-ish和pathspec 。 （旁注： 樹狀術語在Gitglossary中定義，但在這里我將使用更明確的定義。）

“ 樹狀 ”一詞的含義是： 我，Git，如果您命名特定的提交，在這里很好。 我要做的只是查找其內部樹對象，因此，如果出於某些奇怪的原因，您真的可以直接給我。 但是實際上，只要給我一些東西，我就可以將其轉換為提交或樹，然后我將使用該樹，或者使用提交來查找樹。

您在此處提供了origin信息，現在是時候查看另一篇Git文檔了。 （什么， 另一個 ？ 已經？？ ） gitrevisions文檔描述了將名稱（例如master或develop或v2.1 ）轉換為Git對象哈希ID的六步過程。

第一步是檢查.git中是否有一個具有該名稱的文件，該步驟使您可以在陷入沖突的git cherry-pick使用類似CHERRY_PICK_HEAD的名稱。 在這種情況下，它不適用。

第二步是將名稱嘗試為refs/ name 。 第二步讓您在使用git stash時使用stash或stash@{ number } 。 在這種情況下，它也不適用。

第三步是嘗試使用refs/tags/ name作為refs/tags/ name 。 第三步使您可以使用v2.1類的名稱來引用標記 v2.1 。 由於origin可能不是一個有效的標記名-您沒有標記任何提交的origin ，對嗎？-此步驟將失敗，因此Git將繼續執行步驟＃4。

第四步是嘗試使用refs/heads/ name作為refs/heads/ name 。 此步驟允許您使用分支名稱來指定提交。 那就是讓您git checkout master -- somefile 。 由於master 是有效的分支名稱，因此git checkout會找到特定的提交，即master名稱（ master分支的尖端）並使用該提交的樹（請記住），我們正在執行git checkout <tree-ish> [--] <pathspec>...語法，並在此處處理<tree-ish>部分。

但是您沒有名為origin的分支 ，對嗎？ 如果您創建了一個，那么您可能會！ 我建議不要創建一個，但是，如果這樣做了，那么這六個步驟的過程就會停止。 但是，假設您沒有，則過程繼續進行到第五步。

第五步將名稱嘗試為refs/remotes/ name 。 您將擁有一個名為refs/remotes/origin/的目錄，但這不是有效的ref，因此第五步將失敗，該過程將移至最后一步。 如果最后一步失敗，則整個過程都會失敗，但是...

第六步，最后一步，將名稱嘗試為refs/remotes/ name /HEAD 。 由於origin是一個有效的遠程服務器，因此它將存在（嗯，除非您專門刪除了它，否則將不會發生）， 它將是一個有效的提交說明符。 所以第六步成功：它找到refs/remotes/origin/HEAD存在，（可能）名refs/remotes/origin/master ，這也存在，並且名稱提交。

因此，這時就可以滿足整個過程的<tree-ish>部分：Git已將origin轉換為refs/remotes/origin/HEAD ，或者簡稱origin/HEAD ； （可能）與refs/remotes/origin/master或簡稱origin/master ； 這是一個有效的提交，可用於git checkout語法規則＃3或git checkout語法規則＃5＆＃6。

由於我們對＃5/6號規則的工作，我們可以繼續和治療的最后一個參數， develop ，作為<pathspec> 現在，我們必須看看Git的另一篇文檔，即Gitglossary 。 我們可以直接跳轉到pathspec的定義 ，不幸的是，它很長，在這里我將不做所有介紹。

總而言之，pathspec 可以為 ，在這種情況下為 ，只是一個文件名。 因此， develop變成了文件名 ，並且我們已經完成了語法規則＃5 /＃6的所有要求。 Git會執行上面的黃色引用文本中描述的動作，替換文件develop索引和工作樹，或者干脆示數出，如果該文件develop不叫這個名字在提交/存在<tree-ish>那我們選擇了名稱origin 。

Answer 3

git checkout origin develop命令沒有多大意義，因為在Git中僅簽出本地分支。 使用origin develop是指遠程上的develop分支。 您可能打算這樣做：

git checkout develop

假設存在一個遠程跟蹤分支origin/develop （實際上是一個本地分支），則上述內容將告訴Git創建一個新的本地分支，稱為develop ，該分支通過跟蹤分支origin/develop跟蹤遠程分支。