刪除它,你看到在「網絡」視圖中的文物可能是跟蹤您的基於合併的工作流程中。
當合並的合併經營成果提交*(即它不是一個「快進」),版本庫的歷史DAG模型將包括表示兩個分支部分。當非本地分支被推送時,其祖先將包括最初在當地分支上提交的提交。
*通過使用git merge --no-ff
或者因爲兩個分支已經超出其合併基礎。
考慮一個假想的一系列事件和由此產生的歷史DAG +裁判在中央資料庫:
A$ git fetch && git checkout -b foo central/dev
# A works and commits to her local branch
B$ git fetch && git checkout -b bar central/dev
# A and B work and commit to their local branches
A$ git checkout dev && git pull &&
git merge --no-ff foo && git push central dev
# B works and commits to his local branch
C$ git fetch && git checkout -b quux central/dev
# B and C work and commit to their local branches
B$ git checkout dev && git pull &&
git merge --no-ff bar && git push central dev
C$ git checkout dev && git pull &&
git merge --no-ff quux && git push central dev
D$ git fetch &&
git checkout master && git pull &&
git merge --no-ff dev && git push central master
---o---o-------------------------------D master
\ /
\ o---o---o / (was quux in C's local repository)
\ o---o / \ / (was foo in A's local repository)
\/ \/ \/
o-------A---------B---C dev
\ /
o---o----o----o (was bar in B's local repository)
在任何時候都是當地(富,酒吧,QUUX)分公司曾直接推送到中央存儲庫。但是,「他們的」提交被合併提交引用,這些合併提交被推送到中央存儲庫中的dev分支(以及後來的主分支)。
我懷疑GitHub網絡視圖向您顯示這些間接推送的分支。
如果你想消除分支的這種拓撲證據,你將需要移動到基於rebase操作而不是合併操作的工作流(這意味着本地分支的原始「分支點」將被丟棄,這對您的整體工作流程可能是重要的也可能不重要)。
不要陷入困境,試圖讓DAG看起來很「漂亮」。工具不在乎DAG是否「醜陋」,你也不應該。您應該專注於挑選並正確使用生成DAG的分支工作流程,以便讓工具爲您提供有用的工作。
正如我提到的分支本身並不存在於原點(GitHub),而是它的效果可以在GitHub的「網絡」視圖中看到。 – Xubin 2010-06-02 17:15:37
github無法聯繫到您的開發人員計算機,並查看您在那裏得到了什麼 - 如果它位於網絡視圖上,那麼在某些時候它必須已被推入到github中。網絡視圖中存在大量緩存,因此顯示的標籤/分支可能已過時? – deanWombourne 2010-06-02 17:27:13
雖然想到它 - 你確定它是一個分支而不是標籤嗎?什麼'git標籤'輸出? – deanWombourne 2010-06-02 17:29:09