用例：
用戶 A 在從 master 分叉的分支 A 上作業；用戶 B 創建從 master 分叉的分支 B 做一些作業并提交然后洗掉分支 B。用戶 A 可以看到用戶 B 的作業嗎（例如git fetch --all）。用戶 A 從未在分支 B 上作業過。
在這種情況下，分支 B 不會為用戶 A 顯示。
uj5u.com熱心網友回復：
最簡潔的答案是不”。
長答案是Mu：所問的問題實際上毫無意義，除非人們做出一些跳躍式的解釋（我認為大多數人都會這樣做）。原因是分支無關緊要；你不（相當）獲取分支。重要的是提交，所以正確的問題是是否git fetch會獲取這些提交（然后答案通常是“否”??）。
我認為你在這里也有一個錯誤的想法：
例如
git fetch --all
該--all選項git fetch手段所有的遙控器，不是所有分支。
這個答案的其余部分是可選的，但我建議它值得一讀：您會發現答案何時變為“是”。
Git 是如何作業的
我們從以下幾點開始：
Git 存盤庫的核心是一對資料庫：
一個資料庫保存提交和其他 Git 內部物件。它們或多或少地始終存盤每個檔案的每個版本。
但是提交（和其他物件）是用巨大的、對人類無用的、看似隨機的數字（“散列 ID”或“物件 ID”）編號的。為了使這些東西可供人類訪問并因此有用，Git 存盤庫中的另一個資料庫將名稱轉換為內部數字。
Git 存盤庫中的名稱包括分支名稱，但這些并不是唯一的名稱。還有標簽名稱，有趣的東西叫做遠程跟蹤名稱或遠程跟蹤分支名稱，等等。人們（相當錯誤地）有時將遠程跟蹤名稱稱為“遠程分支名稱”，但這非常具有誤導性。
克隆Git 存盤庫的行為意味著讓我獲得所有提交而不是任何分支。（這在某種程度上可以通過各種選項進行修改，并且不會捕獲所有細節，但它是查看克隆的正確起點。）Git 不需要分支。它只需要提交和一些名稱來查找它們。
當我們在本地作業時，在我們從頭開始克隆或構建的 Git 存盤庫中，我們實際上使用分支名稱來完成我們的作業。但是這些分支名稱是在我們的存盤庫中創建的。它們不在任何其他存盤庫中！但是，因為人類是人類，所以我們傾向于在兩個不同的克隆中使用相同的名稱：
Bob 有一個存盤庫。在 Bob 的存盤庫中，Bob 創建了名為
alpha和 的分支beta。我克隆了 Bob 的存盤庫。我沒有得到他的分支名稱：我創建了自己的分支名稱。但是，因為我打算作業與鮑勃，我把我的樹枝
alpha和beta太。
這些是“相同的名稱”，最初它們也可能擁有相同的提交 ID 號。但是我的名字是我的，而鮑勃的名字是鮑勃的。只有當我們同步它們時，它們才會相遇。
當我第一次克隆 Bob 的存盤庫時，我從他那里得到了他的所有提交，而沒有他的分支：我根本沒有分支。但是我的 Git確實記得他的分支名稱。我的 Git 將這些名稱粘貼到我的存盤庫中的遠程跟蹤名稱的一般類別下。也就是說alpha，我得到了，而不是bob/alpha。相反beta，我得到了bob/beta。這些是我的 Git 對 Bob 分支名稱的記憶。
現在，由于我打算處理/使用 Bob 最近發布的相同提交，我選擇這兩個名稱之一，并讓我的 Git為我創建一個同名分支：我現在有一個alpha或一個beta（但不是都）。由于任何名稱都包含一個內部 Git 物件 ID，因此 my alphaor -beta無論我選擇創建哪個 - 都擁有與my bob/alphaor相同的提交哈希 ID bob/beta。這是我從Bob 那里得到所有提交時從 Bob那里得到的哈希 ID ，并將 Bob 的分支名稱變成了我的遠程跟蹤名稱。
如何git fetch作業
Over time, Bob may or may not have made new commits. At some point, I decide I should have my Git, working with my clone, which has my branches (plus of course all the commits, plus my remote-tracking names), call up Bob's Git again, and have Bob's Git connect to Bob's repository.
At this point, Bob has whatever branches he has. His Git (his software, running on his repository) lists out these branch names to my Git (my software, running on my repository). These come with commit hash IDs: those big ugly random-looking numbers for the commit objects.
My Git checks to see whether I have those commits. If I do, great! If not, my Git asks Bob's Git for those commits, which causes a whole conversation to run so that my Git can find out all the new commits Bob has that I don't. My Git downloads all these commits, and now I have all the commits Bob has, again, just like when I first cloned. Finally, now that I have all of Bob's commits—plus maybe my own, on my branches—my Git updates my remote-tracking names to remember Bob's branch names and commits.
Note that this has no effect on any of my branches. I do, however, get updates to my remote-tracking names—and if Bob created a new branch name, and my Git saw it during this git fetch, my Git will create a new remote-tracking name to go with that. If I set fetch.prune or use -p, and Bob deleted some of his branch names, my Git will delete the corresponding remote-tracking names, too. So git fetch updates, for me, the remote-tracking names for the Git I called up.
The key questions here are: What Git did I call up, and what names and commits did that Git have? I say here that I called up Bob's Git, which had Bob's branch names and all the commits Bob has, so we can answer these questions and see what remote-tracking names I have now, and what object hash IDs those names hold.
Introducing "forks" and/or "central repositories"
In the above, I've been using Bob's computer directly. When I run git fetch, I get ssh access (or whatever) to Bob's computer, logging in to it in some way so that I can run Git commands over there. That's fine in some Linux-server-type environments, like a corporate Git setup. But many places don't want to work like this, and/or want to have a single "source of truth" centralized repository, whether that's hosted in-company or on GitHub or whatever.
So now I won't have access to Bob's repository, on Bob's computer. Instead, there's a centralized repo somewhere that—at least initially—has only one branch, named master. Bob will clone that centralized repo and get origin/master and use that to create, in Bob's Git, master. Bob then uses his master to create a new branch name alpha.
When I connect to the central repository, my Git makes my clone, which has all the commits and no branch names and one remote-tracking name origin/master. I (or my Git anyway) use my origin/master to create a branch named master, which I then use to create my branch name beta.
When I run git fetch, my Git goes over to origin. Bob hasn't told the Git over on origin to create any new branch names. So I won't see any of Bob's branch names at all, because I never talk directly to Bob's Git, and I won't see any of Bob's branch names copied over to origin because he has not done that yet.
When Bob eventually runs a git push, he does:
git push -u origin alpha
This makes his Git call up the Git over at origin and offer to it—to the origin Git—any commits Bob has on alpha that origin does not already have.1 They take those commits, and then Bob asks the origin Git to create, on origin, a new branch name, alpha. If the origin Git obeys this request—that's up to the origin Git and any control knobs someone may have installed and adjusted (basic Git doesn't have much here, but most hosting sites do)—then now the origin Git has a branch named alpha.
My Git, calling up the Git at origin, can now see alpha, and create my origin/alpha remote-tracking name (after getting those five, or whatever, new-to-my-Git commits). That's a remote-tracking name for me, and a branch name for origin, but I can only see it because Bob convinced origin to create it.
If Bob decides to make a GitHub-style fork, what he's done is make yet another clone, but this time one hosted on GitHub. Bob's clone is another separate Git repository and this clone has its own branch names. There's a special thing or two about this clone though: when GitHub creates it, GitHub does copy all the branches, so initially that clone has all the same branches as the origin clone I'll be using. Also, as Bob creates new commits and branch names on Bob's GitHub fork, Bob can make pull request to the origin Git. (That's all stuff GitHub offers as add-ons, to make you want to use GitHub rather than doing self-hosting.)
In all these cases, until Bob somehow causes a new branch to come into existence on the origin Git, I can't see Bob's commits. I can only see the branch names that are on origin, which will become my remote-tracking names; and I can only get Bob's commits once he's given them to the origin Git somehow, and made a name on the origin Git so that I—or my Git—can find their commit hash ID numbers.
1This phrasing covers the fact that all the commits that were on master are now on both branches. So the Git at origin has a ton of commits that are on alpha; it's just that Bob has five more commits, or however many Bob made.
Remotes
In the above process, my Git has always had exactly one remote.
When I was using the example where I went directly into Bob's computer—which let me see all of Bob's branches any time I did that—I used the name bob for this remote, so that my remote-tracking names were bob/alpha and bob/beta.
When I was using GitHub as an example, I used the name origin for the remote, so that my remote-tracking names were origin/master and, eventually (once Bob created an alpha there too) origin/alpha.
A remote is primarily a short name for a URL. The URL I might use for Bob's computer might be ssh://bob.company.com/path/to/repo.git. The URL I might use for GitHub might be ssh://[email protected]/company/repo.git.
The git clone command will, by default, make your new clone have, as its (one, single) remote, the remote name origin. This name will store the URL you gave to git clone, so that later, git fetch origin will go back to the same URL and get any new commits from them.
You can, however, have more than one remote. The only constraint here is that each one has to have a unique name. So if I do have direct access to Bob's computer, I can add that to my clone in which origin refers to the GitHub clone ... and now I can access Bob's repository directly, and hence see Bob's branches, as my bob/* remote-tracking names. So now the answer changes from no, I can't see Bob's branches to yes, I can see Bob's branches. I will have origin/master, but also bob/alpha (and bob/master too, unless he deleted his name master).
Now that I have more than one remote, running git fetch --all has a meaning. Before, with just the one remote named origin, git fetch --all means fetch from all remotes, which means fetch from origin, which is what git fetch without --all means: there's just the one remote, so the remote is the one we fetch from.
With two remotes, though, git fetch with no additional qualifier means fetch from some remote. Which one? The git fetch documentation here is not a model of clarity, but the answer currently is:
- if I am on branch B and B has a configured remote of R, that's the one
git fetchuses; - otherwise,
git fetchfalls back on the nameorigin.
(This might change someday.)
If I give git fetch a name like origin or bob, that's the one remote it will fetch from, and there are more options such as "remote groups" and of course --all. Using --all directs git fetch to run git fetch on all remotes, one at a time.2
So: --all is only useful if you've defined two or more remotes. If you have set up remote access to Bob's repository, you can see Bob's branches. This of course requires that you have access to Bob's machine, or Bob's fork on GitHub, or whatever.
2Ideally Git should run multiple parallel fetches, but currently it doesn't.
Conclusion
In the end, the real key here is commits. We get commits by their hash IDs. We find those hash IDs through names—branch names, tag names, remote-tracking names, whatever names. The git fetch command reaches out to some other Git (software repository). By default, it uses their branch names (and their tag names, depending on --tags and other fetch options) to find commits to get, gets those commits, and then creates or updates names in our repository, but with the standard setup, the names we get in our repository for their branch names are our remote-tracking names instead.
The only names we can see are those that they offer us, and they can only offer us the names that they have. So if "their Git" is a centralized repository somewhere, and Bob creates branches in Bob's clone and makes commits there but never sends the names or commits to the centralized repository, the centralized repository never has anything to give us in the first place.
uj5u.com熱心網友回復：
我假設用戶 A 和 B 位于不同的計算機（A 和 B）上，并且主分支存盤在服務器上。
第一的
列出已知分支 B 的存盤庫串列。
- 用戶 B 在計算機 B 上使用的那個。
- 服務器上的那個。如果用戶 B 在服務器上推送了分支 B。
- 其他的 ？（用戶 B 已將分支 B 推送到備份存盤庫上）。
第二
確保分支已從所有這些存盤庫中洗掉。如果沒有，A 可以從這里檢索分支 B（例如：服務器）。
最后
看看reflog，它提供了HEAD（本地）的最近歷史記錄，可以幫助用戶 B 在洗掉后檢索分支 B。一些 git 服務器也有一些相同的功能（比如這里解釋的 github ）。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/329784.html