С Историческим потоком
TL;DR
Эта визуализация (визуализация) является результатом выполнения git diff для всех фиксаций файла с начала времени. Используемая здесь методика визуализации - это поток истории от IBM Collaborative User Experience Research Group.
История - это инструмент для визуализации динамических, развивающихся документов и взаимодействий нескольких сотрудничающих авторов.
Вы можете найти примеры здесь, концепции потока истории здесь и код здесь.
TS;WM
Git используется как система контроля версий во всех крупных проектах по всему миру. Он был там все время, наблюдая за развитием проекта. Он отслеживает каждый файл проекта, запоминает все строки кода, удаленные, обновленные и добавленные. Он знает все, что можно сделать с проектом.
В Git есть множество мощных команд, которые позволяют делать все, что вы когда-либо хотели. Например, git status, вероятно, является наиболее часто используемой командой при любых обстоятельствах. За git status следует монстр git diff. Часто использование git diff остается на поверхностном уровне, где текущее изменение сравнивается с предыдущим изменением. Но, как я уже сказал, это чудовище, эту небольшую команду можно использовать для получения всей истории файлов с информацией о владельце. Когда все эти версии расположены рядом, это больше похоже на сказку, в которой рассказывается, что случилось с файлом. И если существуют файл (ы), которые представляют весь проект, то эта команда рассказывает историю для всего проекта.
Например, package.json в любом проекте node / javascript может считаться репрезентативным файлом проекта. Имеет поле для версии, информации об авторе, зависимостей, скриптов; почти все, что определяет проект на глобальном уровне. С другой стороны, проект требует итераций и времени, чтобы развиться или стать стабильным. Если package.json является репрезентативным файлом проекта, это также должно отражать процесс эволюции. Следовательно, эта визуализация извлекает всю версию файла и диаграммы, которые находятся перед нами.
По сути, git diff - это поток изменений во времени, когда он выполняется в течение времени существования файла. Пока я думал, какой вид визуализации может иметь смысл для решения этого варианта использования, я наткнулся на Историю потока от IBM Collaborative User Experience Research Group.
История - это инструмент для визуализации динамических, развивающихся документов и взаимодействий нескольких сотрудничающих авторов.
Это идеальное совпадение. Итак, вкратце git diff применяется к конкретному файлу с самого начала, и результат выгружается в качестве входных данных для рендеринга визуализации. Никакого ракетостроения там нет. Пожалуйста, ознакомьтесь с концепцией потока истории, прежде чем продолжить. Это очень просто, интуитивно понятно и важно.
Вот как выглядит package.json из React, когда коммиты разнесены по временной метке.
Каждая фиксация представлена тонкими цветными линиями. Две последовательные фиксации связаны, чтобы представить изменения от одной фиксации к другой. Теперь конкретная фиксация состоит из множества фрагментов вклада. Вы можете думать о фрагменте кода, как о фрагменте кода, добавленном или обновленном при фиксации. Участнику назначается цвет. Следовательно, фрагмент в одной строке фиксации получает свойство цвета от участника, который отвечает за создание фрагмента. Следовательно, строка фиксации становится разноцветной.
В этом уродливом примере всего 5 коммитов. Первая фиксация - это, очевидно, создание файла одним участником. Во втором коммите подошел другой парень и внес некоторые изменения. Это не тот парень (участник), потому что после второй фиксации появился новый цвет. Теперь между коммитами тоже есть поток. Вы можете думать о потоке как о сопоставлении позиций фрагмента контента из предыдущей версии в текущую. Прозрачная зона между потоками зазора. Конвергентный разрыв указывает на удаление контента. Расходящийся пробел указывает на добавление контента.
На рисунке ниже показаны коммиты в файле D3 package.json с интервалом во времени.
Тонкие блеклые серые вертикальные линии являются продолжением линий фиксации и служат для справки. Каждая фиксация получает такую строку. Строки фиксации имеют разную длину в зависимости от размера файла, но длина линии расширения вместе со строкой фиксации всегда одинакова для всего экземпляра фиксации. Из-за этого вместе выносные линии лучше показывают распределение коммитов во времени. Это распределение имеет смысл только тогда, когда коммиты разделены отметками времени. Из рисунка можно сделать вывод, что обслуживание проекта (распределение коммитов) было прилично распределено за исключением нескольких исключений (справа меньше кластеризации контрольных линий).
Текущая реализация поддерживает интервалы между коммитами на равном расстоянии (порядковая ось) или по времени. Просмотр сообщества и Последняя фиксация - два режима, поддерживаемые при каждом выборе интервала. В режиме просмотра сообщества все вклады пользователей отображаются в виде обзора с применением одного и того же уровня цветовой кодировки. Но в режиме последней фиксации последние фрагменты в коммитах выделяются путем затухания остальных фрагментов.
Ниже пробелом описаны все эти комбинации с package.json для репо NPM.
Равные интервалы между фиксацией и представлением сообщества. Все коммиты расположены на одинаковом расстоянии, игнорируя временную метку. Этот конкретный экземпляр передает некоторый шаблон фиксации для файла. Мол, до некоторой степени только один коммиттер (синий цвет) вносил преимущественно вклад. Опубликовать почти половину от общего количества коммитов, которые начали вносить другие участники. Еще одно наблюдение: видно только несколько цветов, что говорит о том, что лишь горстке людей разрешено поддерживать проект. Смотрите интерактивную версию здесь.
Равные интервалы между фиксацией и просмотром последней фиксации. Только последние фрагменты в коммите ярко окрашены, в то время как другие более старые фрагменты исчезают. Этот вид дает обзор того, насколько велико было изменение. Этот экземпляр примера демонстрирует, что на начальном этапе проекта трижды произошла серьезная перезапись зависимости (3 большие синие линии).
Временная фиксация с представлением сообщества. Как упоминалось ранее, коммиты размещаются на основе отметки времени. Это представление дает обзор того, как часто файл / репозиторий поддерживается или обновляется. В этом конкретном примере коммиты выполняются почти через равные промежутки времени. Высокая кластеризация серых линий обозначает значительное количество коммитов за единицу времени.
Разнесенная по времени фиксация с просмотром последней фиксации. Последние коммиты отсортированы по времени их совершения в этом представлении. Одно интересное наблюдение с этой точки зрения, когда package.json является предметным файлом, - это цикл выпуска. Посмотрите на верхнюю часть изображения: маленькие синие и красные точки, образующие линию, на самом деле говорят нам об обновлении версии проекта. Для NPM релиз очень последовательный.
Этот вид ничего не говорит наверняка о файле / репо. Например, если файл со временем претерпевает меньшие изменения или не претерпевает никаких изменений, можно сделать вывод, что он не получил большого количества изменений, и в то же время другой может сделать вывод, что модуль стабилен и не требует изменений. Все контекстно. Опять же, с самого начала я предполагал, что package.json является репрезентативным файлом для проекта узла, что не обязательно должно быть верным все время. Сама эта визуализация содержит несколько предположений, несоблюдение которых может дать неверную информацию. Вроде как используется палитра из 24 цветов. Если количество участников превышает 24, уже назначенные цвета назначаются новому пользователю. Следовательно, с визуальной точки зрения вы не сможете выделить более 24 участников.
Вы можете просмотреть все примеры здесь. Вы можете просмотреть код здесь. Дайте мне знать, если вы хотите узнать о коде, который поддерживает viz.
