TL;博士

我必须明确…推到

origin

是的,但不是你想的那样。不过,这可能是最方便的。

长

每个git存储库都是一个独立的实体。远程(如在您自己的存储库中)或fork链接(如在github或bitbucket fork中)记录另一个git存储库的标识,但这两个存储库仍然是独立的实体。因此,每个人都有

它自己的

分支,不与任何其他git存储库共享。

什么

是

与其他git存储库共享,但仅在“共享时间”(

git fetch

和

git push

)是

提交

是的。它们使用原始散列ID共享。不过,这也是分支名称真正进入画面的地方,因为git存储库

发现

它通过它的分支名称(和其他引用)提交,但我们只关注这里的分支名称。

记住,git存储库中分支名称的角色是包含

最后的

承诺将被视为“在”该分支,即

小费承诺

在树枝上。当你使用

git checkout

branch

然后是最终的

git commit

,您的git:

生成新的提交

在设置新提交的

起源

哈希ID到当前提交哈希ID

然后写下

新的

提交的哈希ID到当前

名称

使分支名称再次指向最新的(提示)提交。这个tip commit指向前一个tip,它指向另一个更早的commit,依此类推。

因此,什么

Git推送

Does是:

交出一些提交,理想地,简单地扩展一些现有分支(ES),然后

请求另一个git集

它的

分支名称以记住这些添加的提交的tipmost提交。

(像这样伸出一根树枝

快进

操作)。

如果新提交

不要

只需扩展一些现有的分支,那些特定的名称更新必须是“强制的”:另一个git只会拒绝那些不是快进操作且不是强制的更新请求。

但是,不要求这些分支名称值更改与您自己存储库中的任何实际分支名称相对应。例如,考虑一个常见的(至少对我来说)情况,我正在处理一些特性,并且我编写了六个或更多的提交。从中,我确定一个肯定是个好主意,所以我跑

git rebase -i feature

把那个放在前面。然后我可以跑:

git push origin :for-review

并根据

for-review

是的。从图片上看,此时我自己的存储库中的内容如下所示:

...--o--o

\

*

\

o--o--o--o--o

六宗罪中有五宗没有被钉死,只有一宗有记号

*

这里,已经被推到了,名字

供审查

在存储库中

起源

是的。但我可以继续在自己的存储库中

feature

分支,它比

origin/feature

提前五次犯罪

origin/for-review

是的。我只需要小心记住

*

现在是共享的(这很简单:它有一个

origin/

能找到的名字)。

这就引出了您必须在自己的存储库中执行的操作,以便在

mainline

转到存储库

起源

是的。首先,必须从

干线

以下内容:

git fetch mainline

现在你拥有了

提交

;现在您可以更新

起源

使用,例如:

git push origin mainline/2018.05.x:2018.05.x

它将发送任何

起源

没有,但确实需要这样做,然后创建名称

2018.05.x

在

起源

,指向与自己相同的提交

mainline/2018.05.x

是的。

这当然有点混乱,但关键是你不必

分行名称

为了承诺,只要你有

一些

您(和您的git)可以在自己的存储库中找到提交的名称。到

发送

那些承诺

到

另一个Git,你可以

Git推送

通过散列ID,或

origin/whatever

name,或者您可以创建一个分支名称,或者做您喜欢的任何事情,只要它标识了适当的tip commit。在…的右边

lhs:rhs

但是,名称对必须提供git位于

起源

可以创建或更新。

方便

与

Git推送

(但不是

Git获取

!),如果运行:

git push origin abc

这“意味着”与:

git push origin abc:abc

所以肯定是更多

方便的

在很多方面,每个分支都有自己的本地名称。