Лучший подход к графу GIT с отдельной и отдельной линией для каждой ветви - PullRequest
0 голосов
/ 15 сентября 2018

Я хочу использовать git-flow в качестве рабочего процесса в git. Но у меня проблема с см. git log --graph. Например у меня четыре ветки:

 -master-    -develop-    -feature/sms-    -release/v1.0
    |            |             |                 |

Я хочу видеть каждую ветку в отдельности и индивидуально, как изображение удара: git graph

Что мне делать? или какой инструмент подходит для моих нужд?

1 Ответ

0 голосов
/ 15 сентября 2018

Вы буквально не можете сделать это вообще.Вы можете подделать его для конкретных случаев, что может быть достаточно для вас;но вам придется сделать это самостоятельно, потому что Git этого не сделает.

Причина этого проста: график, который вы показываете, является ложью.Он пытается сделать вид, что Git работает вперёд.Git не: Git работает в обратном направлении.

В Git коммиты, как правило, не на одной ветви .Вместо этого, коммиты находятся на множестве веток одновременно .Вот текстовое представление того же графика:

master:    A--B-----------------------P--...
               \                     /
release:        \                K--M
                 \              /    \
develop:          C-----F------I------R--...
                   \     \    /
feature1:           D--E-----H
                           \
feature2:                   G--J--L--N--...

Это тоже ложь: это означает, что, например, commit A имеет значение only on master,Фактически, коммит A находится на каждой ветви.

Поскольку есть ... частей, которые мы не можем видеть, трудно сказать наверняка, включены ли коммиты G-J-L-N-...больше, чем одна ветвь: нам нужно начинать с конца, как это делает Git, чтобы увидеть реальность, а не ложь.Тем не менее, мы можем сказать, что эти коммиты определенно находятся на feature2 прямо сейчас.Между тем, коммиты C и F находятся на и feature2 и develop.Единственная ветвь, в которой мы не можем быть уверены, содержит последовательность D-E-H: feature2: все четыре из этих коммитов определенно на feature1, но также определенно на develop,потому что I включен develop и I возвращается к H.Между тем, коммит K находится на release, но поскольку K возвращается к I, I равен и на release;поскольку I отслеживает как F, так и H, эти два коммита также включены на release.

Короче говоря, проблема в том, что мы пытаемся работать вперед .Git не работает вперед. Git работает в обратном направлении , начиная с последнего коммита на ветке.Давайте предположим, что у нас действительно есть эти последние коммиты, и перерисовываем все:

A--B-----------------------P   <-- master
    \                     /
     \                K--M
      \              /    \
       C-----F------I------R   <-- develop
        \     \    /
         D--E-----H
                \
                 G--J--L--N   <-- feature2

Этот рисунок правдив, а не ложь (ну, по-видимому, для какого-то хранилища в какое-то время).

Три имени, которые я добавил здесь, являются единственными именами, которые нам нужны , чтобы сохранить все показанные коммиты, поскольку они являются единственными тремя последними коммитами .Мы можем добавить другое имя, например feature1, указывающее, например, на коммит H, и другие имена, которые нам нравятся:

A--B-----------------------P   <-- master
    \                     /
     \                K--M   <-- release
      \              /    \
       C-----F------I------R   <-- develop
        \     \    /
         D--E-----H   <-- feature1
                \
                 G--J--L--N   <-- feature2

Этот последний график представляет собой (не обязательно , но a ) Правдивый способ рисовать вещи.Имя release идентифицирует коммит M, и с M мы - и Git - можем работать в обратном направлении, чтобы найти коммит K, затем продолжить с K до I и затем на оба F и H одновременно.Затем с F и H мы можем вернуться к C и E одновременно и к D (что также возвращается к C);и с C мы можем вернуться к B, а затем к A.Таким образом, коммиты A-B-C-D-E-F-H-I-K-M являются все достижимы с release.

Если мы удаляем имя release, с коммитами ничего не происходит. Все коммитывсе еще там.Они просто больше не содержатся в ветке release, которой больше не существует.Они по-прежнему содержатся в master, потому что master начинается с - заканчивается в? - P, что работает как в M, так и B.Поскольку P достигает M, каждый достижимый коммит с M также доступен с P.

Если вы думаете, что это движение по улице с односторонним движением,в сети улиц с односторонним движением вы на пути к просветлению.Для (намного) больше об этом, я рекомендую работать через веб-сайт Think Like (a) Git .Обратите особое внимание на то, что вам нужно, чтобы ваши инструменты скрывали (некоторые) коммиты от вас (на странице Осмысление отображения ).

НетТо есть, существуют другие системы контроля версий, которые работают так, как вы хотели бы, чтобы Git работал.Mercurial, в частности, очень похож на Git, за исключением того, что коммиты на ветке, на которой они сделаны, навсегда .Каждый коммит находится только в одной ветви.Фиксация, которая содержит ветку, остается неизменной, независимо от того, что вы делаете с именами веток.В Git, поскольку имена перемещаются, в то время как коммиты остаются неизменными, набор ветвей , который содержит любой данный коммит , постоянно меняется!Если вы не готовы к тому, чтобы это случилось с вами в Git, вы будете несчастны при использовании Git.

...