Артефакты, которые вы видите в «сетевом» представлении, вероятно, являются следами вашего рабочего процесса на основе слияния.
Когда операция слияния приводит к фиксации слияния * (т. Е. Это не «ускоренная перемотка вперед»), модель истории хранилища 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)
Ни при каких условиях локальные ( foo , bar , quux ) ветви никогда не передавались напрямую в центральное хранилище. Однако на «их» коммиты ссылаются коммиты слияния, которые помещаются в ветку dev (а затем в ветку master ) в центральном хранилище.
Я подозреваю, что сетевое представление GitHub показывает эти косвенно выдвинутые ветви.
Если вы хотите исключить такие топологические свидетельства ветвей, вам нужно будет перейти к рабочему процессу, основанному на операциях перебазирования вместо операций слияния (это означает, что исходная «точка разветвления» локальной ветки будет отброшена, может или не может быть важным для вашего общего рабочего процесса).
Не увязайте, пытаясь заставить DAG выглядеть «красиво». Инструменты не заботятся о том, являются ли группы DAG «уродливыми», как и вы. Вы должны сосредоточиться на выборе и правильном использовании ветвящегося рабочего процесса, который создает группу доступности базы данных, которая позволяет инструментам выполнять полезную работу за вас.