Местные филиалы отображаются в GitHub "Network" вид - PullRequest
2 голосов
/ 02 июня 2010

Мы используем Git, и наш рабочий процесс состоит из веток 'dev' и 'master', которые находятся на GitHub и в локальном репозитории каждого разработчика. Никакая работа не выполняется непосредственно над 'master' или 'dev', а только в локальных ветвях, и только слияния происходят на 'dev' и позже с 'master'. Мы не выдвигаем локальные ветки на GitHub.

По какой-то причине локальные ветви разработчиков отображаются в представлении «Сеть» на GitHub, и это загромождает диаграмму сети (я должен отметить, что сама ветвь не существует в списке ветвей на GitHub).

Мой вопрос заключается в том, является ли это нормальным поведением и происходит ли оно автоматически как средство показать, откуда происходят изменения в 'dev' и 'master', или это потому, что кто-то по ошибке нажал локальную ветку и удалил ее позже? Если это последнее, есть ли способ убрать беспорядок?

Ответы [ 2 ]

9 голосов
/ 03 июня 2010

Артефакты, которые вы видите в «сетевом» представлении, вероятно, являются следами вашего рабочего процесса на основе слияния.

Когда операция слияния приводит к фиксации слияния * (т. Е. Это не «ускоренная перемотка вперед»), модель истории хранилища 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 «уродливыми», как и вы. Вы должны сосредоточиться на выборе и правильном использовании ветвящегося рабочего процесса, который создает группу доступности базы данных, которая позволяет инструментам выполнять полезную работу за вас.

2 голосов
/ 02 июня 2010

Местные ветки не должны появляться на github, нет. Если кто-то не сказал

git push origin branch_name

нет никакого способа, которым origin (в данном случае github) может знать о ветке.

Если ветвь больше не существует как локальная ветвь, вы можете удалить ее из источника с помощью

git push origin :branch_name
...