Все вы знаете систему Git. Хотя бы слышали — это наверняка. Разработчики, которые пользуются системой, ее или любят, или ругают за сложный интерфейс и баги. Система управления версиями Git де-факто является стандартом в индустрии. У разработчика могут быть мнения о преимуществах Mercurial, но чаще всего приходится мириться с требованием уметь пользоваться Git. Как у любой сложной системы, у нее множество полезных и необходимых функций. Однако, до гениальной простоты добираются не все, поэтому существующая реализация оставляла пространство для совершенствования.
Простыми словами — мудреным приложением было трудно пользоваться. Поэтому в лаборатории Массачусетского Технологического Института взялись за улучшения и отсекли все «проблемные элементы» (ведь то, что для одного проблема, для другого легко может преимуществом). Улучшенную и упрощенную версию назвали Gitless. Её разрабатывали с учетом 2400 вопросов, связанных с Git и взятых с сайта разработчиков StackOverflow.
Команда авторов вычленила самые проблемные места в Git, включая две концепции staging и stashing. Затем они предложили изменения, призванные решить известные проблемы.
Что не так с Git
Многие пользователи жаловались, что Git нуждается в новом интерфейсе. Специалисты даже составили документ Что не так с Git? Концептуальный анализ дизайна. Авторы: S. Perez De Rosso и D. Jackson.
Пример
git checkout < file > // отбросить все изменения в одном файле с последней выгрузки в систему
git reset --hard // отбросить все изменения во всех файлах с последней выгрузки в систему
Эти две строчки — одна из иллюстраций того, как сильно Git нуждался в усовершенствованном интерфейсе. Две разные команды для одной функции с одной разницей в том, что одна для одиночного файла, а вторая — для множества файлов. Часть проблемы также в том, что эти две команды на самом деле не делают в точности одно и то же.
Большинство пользователей Git применяют его для небольшого числа команд, а оставшиеся единицы знают платформу на более глубоком уровне. Получается, что в основном платформа нужна для базовых функций, а большой пласт возможностей остается для слишком узкого круга. Это говорит о неправильной работе Git.
Краткое сравнение базовых функций с предыдущией версией
Одной из ярких характеристик Gitless является то, что версия игнорирует функцию под названием staging. Она позволяет сохранять отдельные части файла. Удобно, но может создавать проблемные ситуации. Ключевое отличие между этой и функцией stashing заключается в том, что вторая скрывает изменения из рабочей области.
Функция stashing прячет черновую работу в рабочем каталоге — отслеживаемые файлы, которые были изменены и сохраняет все в стек с незавершенными изменениями. Все изменения можно применить позже, когда будет удобно. Это нужно, когда вы работаете в одной ветке и в ней все в беспорядочном состоянии, а нужно срочно переключиться на другую ветку. Вы не хотите выгружать код с частично сделанной работой в первой ветке на время паузы.
Функция staging индексирует изменения, внесенные в файл. Если вы пометили файлы staged, Git понимает, что вы подготовили их к выгрузке.
В Gitless нет концепции stashing. Представьте следующую ситуацию. Вы находитесь в разгаре разработки проекта и должны переключиться в другую его ветку, но вы еще не выгрузили в систему свою наполовину выполненную работу. Функция stashing берет сделанные вами изменения и сохраняет их в стек с неоконченными изменениями, которые вы можете восстановить позднее.
Автор руководства по Gitless сообщает, что проблема появляется при переключении между ветками. Может быть сложно запоминать какой из stashes где находится. Ну и вершиной всего этого стало то, что функция не помогает в случае когда вы в процессе мерджа, включающего в себя конфликтные файлы. Таково мнение Переза де Россо.
Благодаря Gitless эта проблема решается. Ветки стали полностью автономными по отношению друг к другу. Это делает работу намного проще и позволяет разработчикам избегать путаницы, когда нужно постоянно переключаться между задачами.
Сохранение изменений
Gitless прячет область стадий в целом, что делает процесс более прозрачным и менее сложным для пользователя. Для решения задач есть намного более гибкие команды «commit». Причем они позволят делать такие действия, как выделение сегментов кода для коммита.
Кроме этого вы можете изменить классификацию любого файла на значения: отслеживаемый, не отслеживаемый или игнорируемый. Не имеет никакого значения, существует ли этот файл в заголовке или нет.
Разветвление процессов разработки
Основная, необходимая для понимания новой версии, идея: ветки в Gitless стали абсолютно независимыми линиями разработки. Каждая из них остается при своей рабочей версией файлов отдельно от других. Пересечений и проблем нет. В какой момент вы бы ни переключались в другую ветвь, содержимое вашего рабочей области сохраняется и файлы, которые имеют отношение к ветке назначения, восстанавливаются. Классификация файлов также сохраняется. Если файл классифицирован по-разному в двух отдельных ветках, то Gitless будет учитывать это.
Проще говоря, в версии Gitless вам не нужно помнить о незагруженных в систему изменениях, которые находятся в конфликте с изменениями в ветке назначения.
Также вы сможете отложить решение конфликтной ситуации, если у вас середина мержда или fuse. Конфликт останется пока вы не переключитесь обратно.
Работа с удаленными репозиториями
Вот синхронизация с прочими репозиториями происходит в обоих программах одинаково.
Ещё одно преимущество новой версии — возможность переключаться к старой без потери кода. При этом ваши коллеги могут быть даже не в курсе, что вы пользуетесь другим ПО.
Руководство по работе с Gitless вы можете изучить на официальном сайте приложения. В документации описано следующее: как создавать репозиторий, сохранять изменения; как работать с ветками; как пользоваться тэгами, работать с удаленными репозиториями.
Что в итоге
Получилось приложение, которое сохраняет функционал Git, но в то же время стало более простым в изучении и использовании командами разработки. На самом деле и до Gitless уже были попытки улучшить Git. Но по словам Филипа Гуо (он ассистент профессора когнитивной науки в Калифорнийском университете Сан-Диего) эта версия впервые достигла целей по преображению интерфейса и действительному решению главны проблем.
Проект использовал строгие методы по созданию программного обеспечения. Это необходимо для вычленения недостатков в одном из наиболее широко применяемых во всем мире программных проектов. В прошлом множество пользователей приводили смешные аргументы как за, так и против Git, но все они не были основаны на научном подходе.
На примере Gitless становится очевидно, что подход упрощения возможно применять и к другим сложным системам. Например, Google Inbox и Dropbox.
Автор: Nuteralie
