git clone - 默認分支

從我的gitlab服務器克隆一個git倉庫後，它沒有簽出master，因爲origin/HEAD指向其他分支的'origin/foo'。在gitlab中，默認分支被設置爲主。git clone - 默認分支

如何將origin/head從'origin/foo'移動到'origin/master'，以便更多克隆自動檢出origin/master？

右克隆後，git的遠程顯示產地狀態：

HEAD branch: foo

遠程Git -r秒：

origin/HEAD -> origin/foo

我想蓋分支指向掌握，雖然 - 在gitlab裏 - 默認分支已經設置爲主。

2016-03-23 rralf

這隻能在服務器端完成。對於GitLab，它在您的項目「設置」（左側邊欄中的最後一項），「默認分支」（第三個文本字段）中完成。

顯然有是目前（2016年3月）的問題，這意味着由GitLab報告的默認分支並不總是一樣的git remote show origin報道的蓋分支。將GitLab默認分支設置爲其他任何設置，然後將其設置回主服務器，可以用於@rralf。

2016-03-23 23:19:23

嚴 - 正如我已經說過的：Gitlab默認分支已經設置爲主 – rralf

是的 - 我知道，它設置爲主！我只是將它設置爲其他東西，並重新設置爲再次掌握。我目前正在克隆它，看看它現在是否有效。 – rralf

好吧，更改gitlab默認分支並將其重置爲主，解決了我的問題。也許你可以將這個提示添加到你的答案中，然後我會接受它。似乎是gitlab內部的一些奇怪的bug ... – rralf

對於這個問題，我想你需要在遠端進行操作。做類似：

git checkout master。

讓HEAD參考主人。

2016-03-23 23:09:30 gzh

遠程端是純粹的git，實際上無法用於原始git命令，因爲它託管在gitlab上。我必須在客戶端做一些魔術，然後將這些更新發送到遠程。 – rralf

@rralf至於本地技巧，我只能想到本地命令別名，即在.gitconfig中設置* clone -b master *的別名，並使用此別名代替原始的克隆命令。 – gzh

除了Paul Hicks' answer，值得補充的是，如果你的客戶端git非常舊（即1.8.5以前，雖然修復被移植到1.8.4.3），但它可能不會選擇正確的反正分支。

當服務器的HEAD參考解析爲提交ID也是多個分支的提示時，會出現此問題。在這些舊版本的git上，clone進程無法理解HEAD -> ...方向，而只是獲取HEAD解決的原始提交ID。它還獲取每個分支的提交標識，然後選擇一些分支 - 哪一個基本上是隨機的 - 具有該提交標識。

較新的客戶端協商符號樣式傳輸，並每次獲得正確的分支。但是，如果您遇到了舊問題，則需要採取一種解決方法，以確保HEAD解決的ID只與一個分支關聯。也就是說，對於匹配的每個其他分支，進行虛擬提交，以便該分支的提示不再是相同的ID。

（如果服務器太舊，這也會失敗，因爲這些舊服務器在協商階段不接受符號傳輸選項，但當然GitLab在過去的十年中並未陷入困境，就像我們贏得的某些Linux發行版't CentOname，ahem。）

2016-03-24 00:00:32 torek

回答