Все вы знаете систему 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.
Комментарии (86)
DesTincT
28.10.2016 21:08не понял, в чём «научный подход» заключается? gl — переключайся между задачами чаще, не концентрируйся и отвлекайся постоянно в 50 веток! Забей на фикс конфликтов, брось и иди делай другую задачу, вперёд)
develop7
29.10.2016 00:41+1Забей на фикс конфликтов
забей пока что, да. уникальная функциональность, емнип
nazarpc
28.10.2016 22:07+3Мне кажется, что интеграция Gitd семейство IDE от JetBrains уже имеет подход гораздо ближе к Gitless. Все эти staging/stashing и правда весьма сложно понять изначально.
akuzmin
30.10.2016 00:50+1Постоянно пользуюсь функцией stashing (Stash / Unstash) в JetBrains PhpStorm, когда нужно срочно переключить ветку. Не совсем понимаю, что вы имеете в виду под 'ближе к Gitless', но вроде бы там вообще нет stashing, а в PhpStorm без этой функции было бы довольно проблематично работать с git проектом.
fox_anthony
28.10.2016 23:43+7Команды git checkout и git reset делают всё-таки разные вещи.
То, что предлагается делать при помощи git reset --hard можно сделать и при помощи git checkout -f (git clean -xfd в случае необходимости).
Для команды git reset --hard выбран почему-то один из частных случаев использования, который совпадает (или почти совпадает) с git checkout -f. Кроме того, команда не предназначена и никогда не используется для манипуляции с файлами, по крайней мере в таком режиме (soft/hard/mixed).
Aingis
29.10.2016 17:10git checkout переключает текущую ветку, причём в таком варианте неизвестно на что. git reset --hard меняет указатель текущей ветки, что важно, если вы хотите сбросить её состояние, особенно в случае несовместимых изменений: не надо разрешать конфликты.
fox_anthony
29.10.2016 21:29git checkout мягко пытается вернуть состояния рабочей копии к состоянию последнего коммита в текущей ветке.
git checkout никак не связан с разрешением конфликтов и никогда не предоставляет такой возможности (попросту говоря этой командой нельзя перевести git в состояние неразрешенных конфликтов.Aingis
30.10.2016 13:14git checkout мягко пытается вернуть состояния рабочей копии к состоянию последнего коммита в текущей ветке.
Нет, если указать ветку или коммит,git checkoutпереключает на неё. Мягко возвращает он только отдельные файлы. В этом и путаница: в зависимости от параметров команда выполняет разные по смыслу действия.
progchip666
28.10.2016 23:52А почему сделано в МТИ я так и не понял
phoenixweiss
29.10.2016 07:13+3Вероятно потому что это Массачусетский Технологический Институт.
Хотя перевод и правда корявый, потому что это международная аббревиатура MIT
P.S. и действительно, я сначала прочитав заголовок приготовился порадоваться за наших, а тут опять не наши.
progchip666
28.10.2016 23:56+2В документации описано следующее: как создавать репозиторий, сохранять изменения; как работать с ветками; как пользоваться тэгами, работать с удаленными репозиториями.
Зачем всё это, когда давно есть графические оболочки. Для нубов они обеспечивают простое освоение, для продвинутых пользователей сохраняют широкие возможности?
RussDragon
29.10.2016 11:34-2Сколько ни пробовал различных графических клиентов, ничего нормального не нашел. Они все были ужасны. Гит – такая штука, для которой трудно сделать столь же гибкий интерфейс, как тот, что дает командная строка.
yar3333
29.10.2016 12:48+3Сейчас SourceTree приблизился по функциональности к TortoiseHg и избавился от жёстких багов, которыми грешил пару лет назад. Использую уже с полгода — доволен, хотя раньше тоже — только командная строка.
DistortNeo
29.10.2016 13:34+2Я вообще считаю, что минимальный функционал по работе с Git должен присутствовать в IDE — программист должен по минимуму отвлекаться при рутинной работе (add/delete/commit/branch).
Про SourceTree согласен, для меня он оказался наиболее приятным клиентом. Приятно также то, что он не является надстройкой консольного гита, а stand-alone клиентом.
progchip666
29.10.2016 13:01Сделать гибкий интерфейс поддерживающий все функции конечно сложно, но приличные клиенты имеют возможность работы с командной строкой. Они автоматизируют применение наиболее простых и частых операций, а специфические команды, которыми обычно пользуешься крайне редко, вполне можно вводить ручками.
Лично я поступаю именно таким образом. Приходится вести параллельно много проектов, время от времени возвращаться к старым чтобы что-то исправить. Вспоминать названия, держать всё в голове для меня просто пытка.
svilgelm
29.10.2016 15:14-1А зачем графические оболочки, когда есть консоль? Для нубов обеспечивает дополнительный опыт работы с консолью, тем самым повышает скорость их обучения, для продвинутых пользователей сохраняет возможность работы в одном интерфейсе, нет нужды в излишнем мышко-кликинге.
progchip666
29.10.2016 16:14Во первых не уверен что консоль быстрее, ну скажем не для всех это быстрее и удобнее.
Во вторых начинающих эти консоли просто пугают.
Система контроля версий полезна не только для суперпродвинутых профи. Поэтому тут я за политику тысячи цветов. Пусть каждый пользуется тем, чем ему удобнее.
В моих условиях, которые я описал выше с окном работать удобнее.
Линуксоидам и тем кто работает с ограниченным количеством проектов консоль может быть удобнее, не буду спорить.
merlin-vrn
29.10.2016 16:56-7Если тебя пугает консоль, даже не думай начинать заниматься программированием. Я серьёзно.
Не консолью единой, безусловно гуи имеет право на существование, каждому своё, но вот что консоль именно пугает — не аргумент в данном случае. Не нравиться может, пугать — вон отсюда и не оборачивайся.progchip666
29.10.2016 18:50+2Спасибо за ценный совет, но во первых я не из пугливых, во вторых не пугает, в третьих он запоздал поскольку уже много лет зарабатываю себе этим на жизнь.
Вот только я как-то упустил момент когда мы вовремя дискуссии в этой ветке успели перейти на ты.merlin-vrn
30.10.2016 21:17-1О-го-го, какой баттхёрт. Хотя, возможно, действительно непонятно. Нет, я с вами на ты не переходил. Вы неправильно поняли.
Вы сказали, что каких-то там новичков пугает, и это моё обращение было к ним. И вот оно было на ты.
И, повторю, я не говорю, что каждый программист должен любить консоль. Но иметь навыки работы с ней, вроде как прокрутка, редактирование командной строки (в том числе обращение к ранее выполненным командам), перенаправление вывода — обязан.
progchip666
29.10.2016 18:56+6Я успел за свою жизнь повидать как немало отставших от жизни лузеров, которые любили пользоваться консоль, так и хороших в своей области программистов которые пользовались ей в случае крайней необходимости.
Более чем странного подхода к разделению людей на программистов и не программистов в зависимости от влюблённости с консоль я не встречал.
mmatrosov
07.11.2016 14:33-2Полностью согласен. В 99.9% случаев для операций с репозиторием использую графический клиент (SmartGit). В остальных 0.1% случаев гуглю "how to X in git". С удивлением смотрю, как бородатые дядьки в консоли по 30 секунд делают то, что я бы сделал в графическом клиенте за 3 секунды. С ещё большим удивлением смотрю как некоторые джуниоры пытаются пользоваться консолью, потому что "круто", "кроссплатформенно" и "не ограничивает возможности".
DistortNeo
29.10.2016 16:58+1Некоторые вещи в графическом виде делать действительно проще, например, просмотр дерева файлов с индикацией статуса каждого файла вместо спама консольных команд, различные операции с файлами типа переноса ветки из одного места в другое.
DistortNeo
29.10.2016 16:40+1Думаю, это исключительно вопрос холивара «IDE против консоли». И те, и другие чувствуют себя вполне комфортно: нормальные IDE имеют встроенные функции систем контроля версий, а сторонники дзена используют плагины для vim, чтобы не переключаться в консоль лишний раз.
Maccimo
29.10.2016 16:08-1Разобраться с командной строкой намного проще и быстрее, чем угадать то, в какую дыру очередной формошлёп засунул нужную функцию и реализована ли поддержка этой функции вообще или же всё время ушло на впиливание анимации, эмодзи и нескучных обоев.
merlin-vrn
29.10.2016 17:02+9Ну уж нет, иной раз быстрее полазить по менюшкам, чем угадать, как очередной очкарик назвал эту функцию и как тут вообще получить справку по имеющимся функциям. A то у одних --help и --longhelp, другие не умеют --help — только -h и всё тут, третьи по -h/--help выдают невнятный бриф и посылают в man, четвёртые в info — поубивал бы таких, у пятых вообще документация только на сайте онлайн, а у шестых — только оффлайн, в pdf, и не покрывает функционал полностью — копайся в сырцах, это же тебе надо.
sumanai
29.10.2016 19:23Это ещё что, а вот регистрозависимость аргументов… Правда это уже про обычную консоль, не относится именно к git.
Maccimo
30.10.2016 08:56+1Практически все консольные утилиты при запуске с ошибочными параметрами указывают ключ, по которому можно получить справку. Я, во всяком случае, с ходу исключений вспомнить не могу.
Так что запускаем утилиту с ключом --help и получаем либо справку, либо имя параметра для получения справки. Угадывать не нужно.
ncix
29.10.2016 23:22+13Знаете что меня убивает в консольных утилитах? Чтобы ими пользоваться нужно постоянно иметь графический интерфейс в виде браузера с быстрым интернетом и сотней вкладок, где можно прочитать как что-то сделать в этой самой консоли. Да, если ты там делаешь одно и то же — можно и запомнить, но куда чаще приходится делать совершенно разные вещи единственный раз в жизни. Вот и выходит что пользуешься графическим интерфейсом (Google->Stackoverflow->мануалы) а потом руками переносишь это в консоль. Не самый эффективный метод.
Cheater
30.10.2016 01:04+3Обычно есть локальная справка. У привычки лезть за любой справкой в сеть есть и негативный эффект, особенно он наблюдается среди *nix пользователей в последние годы — люди вообще разучиваются пользоваться локальными man страницами и программами info/man в принципе.
Saffron
30.10.2016 01:12+2> он наблюдается среди *nix пользователей в последние годы
При этом надо не забывать, что программист — тоже пользователь. Сегодня человек как пользователь не читает маны, а завтра он как программист не пишет их. Например, вместо этого снимает видео урок и выкладывает на ютуб.
ncix
30.10.2016 01:24+2обычно да, но:
1. листать ман в консоли и удобно браузить по десятку вкладок — две большие разницы.
2. чтобы почитать локальную справку нужно хотя бы знать какой утилитой пользоваться а затем её установить, если её нет. Чтобы понять что и как устанавливать — нужен браузер.
3. некоторые утилиты имеют гигантское количество параметров и опций, и вам возможно придется просмотреть их все, вместо того чтобы найти в браузере готовое решение своей задачиmerlin-vrn
30.10.2016 21:221. Очень удобно, у меня часто два окна консоли рядом: одно с маном, в другом команду пишу. Какой браузер?
2. Чо? А чтобы найти подходящую графическую утилиту — браузер не нужен? А уж установить — ну хватит, apt-get install или emerge или yum и всё. Кстати, так вообще и утилиту поискать можно, часто даже находится, браузер оказывается не нужен.
3. Команды с гигантским числом параметров обычно рассчитаны на какие-то менеджеры для автоматизированного запуска. Например, gcc имеет очень дофига параметров, но вообще обычно руками его не вызывают, а используют make.ncix
30.10.2016 22:192. Нужен конечно, это и есть использование графического интерфейса, которое я предпочитаю консоли.
Кстати, так вообще и утилиту поискать можно, часто даже находится, браузер оказывается не нужен.
это как?
progchip666
31.10.2016 23:36+1С таким же успехом можно иметь перед вместо «мана» графический интерфейс.
К тому же я например программист для встраиваемых систем. у меня перед глазами часто кроме IDE для программирования микроконтроллеров ещё мануал по MCU, пара мануалов по чипам, работающим под управлением микроконтроллера, и AltiumDesigher Мне только ещё консоли с мануалом не хватает. У меня и так на столе три монитора стоит — на третий виртуальный осциллограф выведен.
Cheater
31.10.2016 10:54+1> 1. листать ман в консоли и удобно браузить по десятку вкладок — две большие разницы.
Здесь не всё так однозначно… В сети лежит огромное количество информации, в том числе разжёванных howto и т.д., а веб-поиск очень интерактивен и прост («ок гугл, git stash unmerged files»), но на этом преимущества веба кончаются.
groff (aka «man-страница») и info — сто лет существующие форматы, давно ставшие стандартом документации в юниксах, я могу смотреть их на машине без подключения к сети, в какой захочу программе (man и info это далеко не единственные программы просмотра man/info, я например пользуюсь другим просмотрщиком), могу индексировать их, производить сложный поиск, производить поиск только в открытых файлах, делать что угодно, а ещё в юниксы традиционно кладут кучу локальных howto и примеров в довесок к man-страницам (собственно, веб-поиск обычно и приводит просто-напросто на выложенную в сеть man- или howto-страницу).
Справка в виде веб-страницы в сети: требует наличия интернет-подключения и запуска одного из самых тяжеловесных приложений — веб-браузера, а возможности навигации/поиска ограничены тем, что заложено в веб-страницу, браузер и поисковик. Для демонстрации возможностей своего браузера в этой области попробуйте решить задачу «из 30 открытых вкладок быстро найти те, заголовок или содержимое которых содержат слово git».
> 2. чтобы почитать локальную справку нужно хотя бы знать какой утилитой пользоваться а затем её установить, если её нет. Чтобы понять что и как устанавливать — нужен браузер.
Если речь идёт именно о «консольных» форматах, info и встроенной помощи, то нагуглить, что man-страницы открываются утилитой man, info-страницы открываются утилитой info, а консольный вывод смотрится less и т.д., достаточно один раз в жизни.=))) То же самое с изучением этих утилит: требуется потратить некоторое время, но это действие, выполняемое 1 раз в жизни. Эти утилиты как правило есть в системе и ничего ставить не надо.
> 3. некоторые утилиты имеют гигантское количество параметров и опций, и вам возможно придется просмотреть их все, вместо того чтобы найти в браузере готовое решение своей задачи
Для этого есть поиск по локальной справке, в том числе нечёткий.
ValdikSS
03.11.2016 14:51Предполагаю, это потому, что нет действительно хорошей документации по первоначальной работе с Linux. Небольшой, до 100 страниц, где бы описывались возможности стандартных утилит, их предназначение, какие-то широко используемые технологии и подсистемы (DKMS, systemd).
Вот, например, для тех, кто не любит читать маны в консоли, есть опция-H, которая сгенерирует HTML и откроет его в браузере.
Или, например, если у вас есть какая-то объявленная через define константа в C-коде, но вы не знаете, какой заголовочный файл вам подключить, можно выполнить полнотекстовый поиск по man'ам:man -Hfirefox 2 open
Как об этом узнать, не читая man man целенаправленно?man -K O_DSYNC
cc: merlin-vrn, CheaterDistortNeo
03.11.2016 16:05Вот, например, для тех, кто не любит читать маны в консоли, есть опция -H, которая сгенерирует HTML и откроет его в браузере.
И вот, что она выдала:
man -Hfirefox 2 open man: command exited with status 3: /usr/bin/zsoelim | /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e UTF-8 | tbl | groff -mandoc -Thtml
merlin-vrn
03.11.2016 16:31-1Никак. И не нужно. Хочешь использовать все возможности — прочитай весь ман. Потом решай, что из этого тебе нужно.
ValdikSS
03.11.2016 16:36А что делать, если вы не знаете, какой ман читать? Вот, например, вы просто не знаете о команде «man», или знаете, чего вам нужно добиться, но не знаете о конкретной утилите, которая сделает это.
Cheater
07.11.2016 13:57+1> Как об этом узнать, не читая man man целенаправленно?
Никак =) Вроде бы такого канонического документа «по общим вопросам» нет.
Самое близкое, что я знаю, — это проект tldp.org. Но, как правило, по конкретной утилите или системному компоненту в интернете всегда можно быстро найти хороший вводный курс. Я сам грешен тем, что вместо мануалов порой гуглю быстрые howto от сторонних авторов.
Maccimo
30.10.2016 09:21+2куда чаще приходится делать совершенно разные вещи единственный раз в жизни.
Странно, мне, наоборот, куда чаще приходится делать весьма небольшое подмножество вещей.
В случае с git это init / add / commit / push / pull / rebase / merge / diff / difftool / mergetool / reset / cherry-pick.
Синтаксис запоминается довольно быстро, в крайнем случае есть локальная справка.
Sild
29.10.2016 00:06+2Это нужно, когда вы работаете в одной ветке и в ней все в беспорядочном состоянии, а нужно срочно переключиться на другую ветку.
Вот никогда этого не понимал. Сделай коммит локальный, можно --amend прикрутить. Не хочешь забыть изменения — сделать коммит а потом резет, изменения снова станут показываться.
Куда хуже когда изменения из стека внезапно применяются не туда. Без всяких мержей.develop7
29.10.2016 00:30+1Сделай коммит локальный, можно --amend прикрутить. Не хочешь забыть изменения — сделать коммит а потом резет, изменения снова станут показываться.
да, или stash. небось руки не отвалятся.
afschr
29.10.2016 02:50Также обратный случай, иногда начинаю фиксить в неправильной ветке. С git checkout легко просто переключиться на правильную, все изменения останутся на месте. Тут Gitless поступит как проще для новичка, но при этом лишаешься гибкости.
hrustash
29.10.2016 13:16Тоже сначала про это подумал.
Но там на скрине про бранчи есть коммент внизу, мол, можно протащить все с собой, добавив флаг.
ncix
30.10.2016 00:41Это нужно, когда вы работаете в одной ветке и в ней все в беспорядочном состоянии, а нужно срочно переключиться на другую ветку.
А почему бы не вытащить исходники другой ветки в отдельную папку и в ней спокойно работать?
symbix
29.10.2016 00:42+2[irony]Они сделали из гита меркуриал![/irony]
Ну, вообще, я не знаю. Когда перешел с меркуриала на гит, первые несколько дней, конечно, плевался и чертыхался, но потом и сам не заметил, как привык. Просто надо понимать, как гит устроен — тогда и с командами проблем не будет. Ну, да, гит достаточно «низкоуровневый», но в этом есть и плюсы.
bromzh
29.10.2016 01:04+3На примере Gitless становится очевидно, что подход упрощения возможно применять и к другим сложным системам. Например, Google Inbox и Dropbox.
Нет, это как-то совсем не очевидно. И что не так с инбоксом?
psЕсли вывод не придумывается, можно и без него.
smile616
29.10.2016 13:16Похоже автор имела в виду, что Google Inbox и Dropbox — ещё два примера применения упрощения сложных систем.
P/S тоже сначала не мог понять, что не так с инбоксом.
lookid
29.10.2016 02:22> на научном подходе
А где наука? Чем это лучше git + alias? Или опять сидеть алиасы перепиливать, но уже под Gitless? Скажите честно, учоные, это чей-то бакалавр «на отвались»?
geekmetwice
29.10.2016 02:52-28Все ходят вокруг этого git с такими умными лицами, будто это нечто гениальное! Эй, люди, опомнитесь — это писал тот же троечник, что наковырял Линукс! Причём написал git ДЛЯ СЕБЯ (ну и for fun, конечно! :) ). С чего вы вдруг решили, что ЭТИМ можно пользоваться для серьёзных продуктов?
В мире тысячи команд, в каждой своя культура и способы работать сообща. То, что один очкарик мержит себе в линукс патчи, ещё не делает софт УДОБНЫМ и непротиворечивым. Собственно, потому Mercurial и применяется не менее широко, что сделан по-человечески.
Akon32
29.10.2016 11:34+7Git задумывался как «тупой трекер контента», и реализовывался соответственно. Но внезапно стал фактически отраслевым стандартом, обойдя всех конкурентов (можете погуглить современные рейтинги систем контроля версий — раз, два). И это при достаточно невменяемом интерфейсе, от которого плюются все новички.
stanr
29.10.2016 13:16Вот, что бывает когда гуманитарий берется за рассуждения над сугубо техническими деталями…
100% вопросов и недостатков git обсуждаемых выше решается надстройками — gui интерфейсами вроде tortoisegit и веб версиями вроде github.
Остальное — велосипеды с квадратными колесами, на 99% копирующими оригинал(в том числе логику\исходные коды) с ничтожными изменениями, в надежде «выехать» на этом.
vintage
29.10.2016 13:58-4Ну а родовую травму гита с коммитами не привязанными к веткам они побороли? А то все эти костыли с добавлением имени ветки в сообщение коммита, через хук порядком надоели.
Source
29.10.2016 19:06+4Странно, что умолчали о замене интерактивным командам git, типа
git add -i,git rebase -i.
Я вообще без них workflow в git не представляю.
Cheater
30.10.2016 00:39+1> git checkout < file > // отбросить все изменения в одном файле с последней выгрузки в систему
> git reset --hard // отбросить все изменения во всех файлах с последней выгрузки в систему
> Две разные команды для одной функции с одной разницей в том, что одна для одиночного файла, а вторая — для множества файлов.
Команда для отбрасывания изменений во многих файлах или в целом каталоге проста и логична и ничем не отличается от отбрасывания изменений в одном файле: git checkout file1 file2 dir3 dir4… То, что другие команды (например git reset --hard или git checkout -f) способны произвести тот же эффект, не значит, что «в гит изменение в одном файле откатывается одной командой, а изменение во всех файлах — другой!11». В общем, кто-то ниасилил git checkout --help.
BlackRaven86
30.10.2016 01:04+3Разработчики, которые пользуются системой, ее или любят, или ругают за сложный интерфейс и баги.
За какие это баги ругают git?
acmnu
31.10.2016 11:27Я думаю имелось ввиду, что некоторые операции в git заведомо опасны и могут необратимо сломать локальный индекс. Это сделано не зря, поскольку для больших проектов (в первую очередь ядро Линукс) это необходимо, но для новчиков это минное поле: нашел инструкцию в интернете, ошибся, клонируйся заново. На StackOverflow это распространненый класс вопросов по git.
Akon32
31.10.2016 12:30+1Из личного опыта (под Windows):
- В какой-то версии, ещё в 2012 году, вместо системной кодировки (cp1251 которая) имён файлов стала использоваться UTF-8. Репозиторий пришлось конвертировать, благо на тот момент мы git серьёзно не использовали (в hg подобная проблема, кажется, и позже была, но только при переходе linux<->windows).
- Где-то год назад git перестал адекватно воспринимать старые DOS-овские имена наподобие ABC~1.TXT (закрыли какую-то уязвимость). Были проблемы с добавлением/удалением/checkout-ом этих файлов, то есть файл был отмечен как изменённый, и ничего с этим поделать нельзя. Переименовать тоже просто так нельзя.
- Регистрозависимость имён файлов. "Любимый" баг. Git на Windows и сегодня не подозревает, что ABC и abc — одно и то же. Если где-то в диффе изменений встречается переименование ABC->abc, git при слиянии этих изменений в другую ветку не может сделать это переименование, и в дереве файлов появляются оба. А затем — проблемы с checkout-ом и с удалением "лишних" файлов.
Не уверен, что ругают именно за эти баги, но проблемы бывают.
michael_vostrikov
31.10.2016 14:11Еще бывает, когда есть сразу 2 файла ABC и abc. Висит один измененный файл, через stash не убирается, ни merge ни rebase не сделать. Исправить можно, если отключить в реестре флаг obcaseinsensitive, примонтировать диск в cygwin с опцией posix=1, и сделать git reset --hard в git, установленном из репозиториев cygwin.
BlackRaven86
02.11.2016 11:00Проблемы бывают у всех, но "ругают за баги" подразумевает, что программа глючная и пользователи постоянно сталкиваются с проблемами. В случае гита, это не так.
stranger777
30.10.2016 09:33Ну да, ломать — не строить. Для отдельного файла можно отдельную ветку сделать. Может быть я в чём-то не прав, но по-моему самого базового функционала git уже за глаза, если аккуратно его использовать. А дезть в дебри — усложнять себе работу.
andreysmind
30.10.2016 12:09-1Это MIT, эти парни не могут ошибаться! Если NIH разработка имеет солидный бренд, то это наверняка очень крутая штука.
dimka11
31.10.2016 22:24На примере Gitless становится очевидно, что подход упрощения возможно применять и к другим сложным системам. Например, Google Inbox и Dropbox.
Что сложного в этих системах?
mva
02.11.2016 12:331) А почему не указано что перевод?
Вот, честно, обсмотрел везде со всех сторон пост и не нашёл плашки перевода. Опять замечательные улучшения интерфейса от ТМ или её и вправду нет?
2) Пока читал, то и дело возникал баттхёрт от непонимания автором (кем бы он ни был) ни специфики работы vcs, ни конкретно git'а, ни даже что какие команды делают.
ИМХО, такое чтиво вредно для здоровья.
Saffron
Если выбирать консольные клиенты для git, то я предпочту magit.
n-name
Скажите, в чем его плюсы? Только начинаю работать с git и хочется знать.
Saffron
1) псевдотерминальный интерфейс с читабельным представлением веток
2) поддерживает все воркфлоу
3) удобно структурированные действия. Работа реализована в форме диалога — сначала ты запрашиваешь основное действие, потом magit просит тебя уточнить параметры.
4) очень просто коммитить один файл кусочно. Просто выделяешь текст, который хочешь закоммитить и коммитишь только его.
5) в качестве вишенки на торте — автосейв в git. При этом создаётся отдельный индекс, не связанный ни с какой веткой, чтобы не засирать их.
ser-mk
К слову о консольных клиентах, есть прекрасный stand-alone клиент tig. Управление stashing'ом и интерактивное индексирование присутствует, ну и еще много всяких плюшек есть)
progchip666
Я предпочитаю TortoiseHg, правда он не совсем консольный, скорее уже графический. Но очень удобен для новичков
akuzmin
Также пользуюсь им иногда. Еще очень удобен встроенный графический интерфейс Git/Github в PhpStorm / WebStorm. Также, в случае глюков Git, неудачных merge и прочего, изменения можно восстановить с помощью встроенного в PhpStorm / WebStorm дополнительного локального контроля версий (Local history).
enterpub
Может вы имели в виду tortoisegit? TortoiseHg применяется только для Mercurial
progchip666
Вы правы, я использую Mercurial
sumanai
При помощи плагина его можно применить и для git, что я и делаю.
enclis
Magit только для Emacs.
Saffron
Emacs — это такая среда для запуска интерактивных приложений. Как браузер, только в консоле. Не надо думать, что это текстовый редактор. Это интерпретатор лиспа и набор экранных гаджетов для работы с ним. Есть кнопочки, формы и т.д.