Сделано в МТИ: система контроля версий Gitless


    Все вы знаете систему 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.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 93

      +2
      Если выбирать консольные клиенты для git, то я предпочту magit.
        +3
        Скажите, в чем его плюсы? Только начинаю работать с git и хочется знать.
          +3
          1) псевдотерминальный интерфейс с читабельным представлением веток
          2) поддерживает все воркфлоу
          3) удобно структурированные действия. Работа реализована в форме диалога — сначала ты запрашиваешь основное действие, потом magit просит тебя уточнить параметры.
          4) очень просто коммитить один файл кусочно. Просто выделяешь текст, который хочешь закоммитить и коммитишь только его.
          5) в качестве вишенки на торте — автосейв в git. При этом создаётся отдельный индекс, не связанный ни с какой веткой, чтобы не засирать их.
            0
            К слову о консольных клиентах, есть прекрасный stand-alone клиент tig. Управление stashing'ом и интерактивное индексирование присутствует, ну и еще много всяких плюшек есть)
            +4
            Я предпочитаю TortoiseHg, правда он не совсем консольный, скорее уже графический. Но очень удобен для новичков
              +1
              Также пользуюсь им иногда. Еще очень удобен встроенный графический интерфейс Git/Github в PhpStorm / WebStorm. Также, в случае глюков Git, неудачных merge и прочего, изменения можно восстановить с помощью встроенного в PhpStorm / WebStorm дополнительного локального контроля версий (Local history).
                +3
                Может вы имели в виду tortoisegit? TortoiseHg применяется только для Mercurial
                  +1
                  Вы правы, я использую Mercurial
                    0
                    не совсем консольный, не совсем для git, но тем не менее клиент :)
                    +3
                    TortoiseHg применяется только для Mercurial

                    При помощи плагина его можно применить и для git, что я и делаю.
                      0
                      а что за плагин? И насколько результат отличается от tortoisegit?
                        0
                        hg-git, как ни странно, есть в стандартной поставке, только включить в конфиге нужно. С tortoisegit плотно не работал, поэтому об отличиях сказать не могу.
                          +1

                          Очень сильно. TortoiseGit — он как TortoiseSVN, интегрируется в проводник и всё, через него делается. А TortoiseHG как SmatGit и тп — отдельное приложение со всем необходимым.

                    0
                    Magit только для Emacs.
                      +2
                      Emacs — это такая среда для запуска интерактивных приложений. Как браузер, только в консоле. Не надо думать, что это текстовый редактор. Это интерпретатор лиспа и набор экранных гаджетов для работы с ним. Есть кнопочки, формы и т.д.
                    0
                    не понял, в чём «научный подход» заключается? gl — переключайся между задачами чаще, не концентрируйся и отвлекайся постоянно в 50 веток! Забей на фикс конфликтов, брось и иди делай другую задачу, вперёд)
                      +1
                       Забей на фикс конфликтов

                      забей пока что, да. уникальная функциональность, емнип

                      +3

                      Мне кажется, что интеграция Gitd семейство IDE от JetBrains уже имеет подход гораздо ближе к Gitless. Все эти staging/stashing и правда весьма сложно понять изначально.

                        +1
                        Постоянно пользуюсь функцией stashing (Stash / Unstash) в JetBrains PhpStorm, когда нужно срочно переключить ветку. Не совсем понимаю, что вы имеете в виду под 'ближе к Gitless', но вроде бы там вообще нет stashing, а в PhpStorm без этой функции было бы довольно проблематично работать с git проектом.
                        +7
                        Команды git checkout и git reset делают всё-таки разные вещи.
                        То, что предлагается делать при помощи git reset --hard можно сделать и при помощи git checkout -f (git clean -xfd в случае необходимости).
                        Для команды git reset --hard выбран почему-то один из частных случаев использования, который совпадает (или почти совпадает) с git checkout -f. Кроме того, команда не предназначена и никогда не используется для манипуляции с файлами, по крайней мере в таком режиме (soft/hard/mixed).

                          0
                          git checkout переключает текущую ветку, причём в таком варианте неизвестно на что. git reset --hard меняет указатель текущей ветки, что важно, если вы хотите сбросить её состояние, особенно в случае несовместимых изменений: не надо разрешать конфликты.
                            0
                            git checkout мягко пытается вернуть состояния рабочей копии к состоянию последнего коммита в текущей ветке.
                            git checkout никак не связан с разрешением конфликтов и никогда не предоставляет такой возможности (попросту говоря этой командой нельзя перевести git в состояние неразрешенных конфликтов.
                              0
                              git checkout мягко пытается вернуть состояния рабочей копии к состоянию последнего коммита в текущей ветке.
                              Нет, если указать ветку или коммит, git checkout переключает на неё. Мягко возвращает он только отдельные файлы. В этом и путаница: в зависимости от параметров команда выполняет разные по смыслу действия.
                          0
                          А почему сделано в МТИ я так и не понял
                            +3
                            Вероятно потому что это Массачусетский Технологический Институт.

                            Хотя перевод и правда корявый, потому что это международная аббревиатура MIT

                            P.S. и действительно, я сначала прочитав заголовок приготовился порадоваться за наших, а тут опять не наши.
                            +2
                            В документации описано следующее: как создавать репозиторий, сохранять изменения; как работать с ветками; как пользоваться тэгами, работать с удаленными репозиториями.

                            Зачем всё это, когда давно есть графические оболочки. Для нубов они обеспечивают простое освоение, для продвинутых пользователей сохраняют широкие возможности?
                              –2
                              Сколько ни пробовал различных графических клиентов, ничего нормального не нашел. Они все были ужасны. Гит – такая штука, для которой трудно сделать столь же гибкий интерфейс, как тот, что дает командная строка.
                                +3
                                Сейчас SourceTree приблизился по функциональности к TortoiseHg и избавился от жёстких багов, которыми грешил пару лет назад. Использую уже с полгода — доволен, хотя раньше тоже — только командная строка.
                                  +2
                                  Я вообще считаю, что минимальный функционал по работе с Git должен присутствовать в IDE — программист должен по минимуму отвлекаться при рутинной работе (add/delete/commit/branch).

                                  Про SourceTree согласен, для меня он оказался наиболее приятным клиентом. Приятно также то, что он не является надстройкой консольного гита, а stand-alone клиентом.
                                  0
                                  Сделать гибкий интерфейс поддерживающий все функции конечно сложно, но приличные клиенты имеют возможность работы с командной строкой. Они автоматизируют применение наиболее простых и частых операций, а специфические команды, которыми обычно пользуешься крайне редко, вполне можно вводить ручками.
                                  Лично я поступаю именно таким образом. Приходится вести параллельно много проектов, время от времени возвращаться к старым чтобы что-то исправить. Вспоминать названия, держать всё в голове для меня просто пытка.
                                    0
                                    У нас в команде у любителей графических клиентов прижился gitKraken — вполне симпатичная штука.
                                    –1
                                    А зачем графические оболочки, когда есть консоль? Для нубов обеспечивает дополнительный опыт работы с консолью, тем самым повышает скорость их обучения, для продвинутых пользователей сохраняет возможность работы в одном интерфейсе, нет нужды в излишнем мышко-кликинге.
                                      0
                                      Во первых не уверен что консоль быстрее, ну скажем не для всех это быстрее и удобнее.
                                      Во вторых начинающих эти консоли просто пугают.
                                      Система контроля версий полезна не только для суперпродвинутых профи. Поэтому тут я за политику тысячи цветов. Пусть каждый пользуется тем, чем ему удобнее.
                                      В моих условиях, которые я описал выше с окном работать удобнее.
                                      Линуксоидам и тем кто работает с ограниченным количеством проектов консоль может быть удобнее, не буду спорить.
                                        –7
                                        Если тебя пугает консоль, даже не думай начинать заниматься программированием. Я серьёзно.

                                        Не консолью единой, безусловно гуи имеет право на существование, каждому своё, но вот что консоль именно пугает — не аргумент в данном случае. Не нравиться может, пугать — вон отсюда и не оборачивайся.
                                          +2
                                          Спасибо за ценный совет, но во первых я не из пугливых, во вторых не пугает, в третьих он запоздал поскольку уже много лет зарабатываю себе этим на жизнь.
                                          Вот только я как-то упустил момент когда мы вовремя дискуссии в этой ветке успели перейти на ты.
                                            –1
                                            О-го-го, какой баттхёрт. Хотя, возможно, действительно непонятно. Нет, я с вами на ты не переходил. Вы неправильно поняли.

                                            Вы сказали, что каких-то там новичков пугает, и это моё обращение было к ним. И вот оно было на ты.

                                            И, повторю, я не говорю, что каждый программист должен любить консоль. Но иметь навыки работы с ней, вроде как прокрутка, редактирование командной строки (в том числе обращение к ранее выполненным командам), перенаправление вывода — обязан.
                                              0
                                              С этим я не спорю
                                            +6
                                            Я успел за свою жизнь повидать как немало отставших от жизни лузеров, которые любили пользоваться консоль, так и хороших в своей области программистов которые пользовались ей в случае крайней необходимости.
                                            Более чем странного подхода к разделению людей на программистов и не программистов в зависимости от влюблённости с консоль я не встречал.
                                              –2

                                              Полностью согласен. В 99.9% случаев для операций с репозиторием использую графический клиент (SmartGit). В остальных 0.1% случаев гуглю "how to X in git". С удивлением смотрю, как бородатые дядьки в консоли по 30 секунд делают то, что я бы сделал в графическом клиенте за 3 секунды. С ещё большим удивлением смотрю как некоторые джуниоры пытаются пользоваться консолью, потому что "круто", "кроссплатформенно" и "не ограничивает возможности".

                                            +1
                                            Некоторые вещи в графическом виде делать действительно проще, например, просмотр дерева файлов с индикацией статуса каждого файла вместо спама консольных команд, различные операции с файлами типа переноса ветки из одного места в другое.
                                            +1
                                            Думаю, это исключительно вопрос холивара «IDE против консоли». И те, и другие чувствуют себя вполне комфортно: нормальные IDE имеют встроенные функции систем контроля версий, а сторонники дзена используют плагины для vim, чтобы не переключаться в консоль лишний раз.
                                            –1
                                            Разобраться с командной строкой намного проще и быстрее, чем угадать то, в какую дыру очередной формошлёп засунул нужную функцию и реализована ли поддержка этой функции вообще или же всё время ушло на впиливание анимации, эмодзи и нескучных обоев.
                                              +9
                                              Ну уж нет, иной раз быстрее полазить по менюшкам, чем угадать, как очередной очкарик назвал эту функцию и как тут вообще получить справку по имеющимся функциям. A то у одних --help и --longhelp, другие не умеют --help — только -h и всё тут, третьи по -h/--help выдают невнятный бриф и посылают в man, четвёртые в info — поубивал бы таких, у пятых вообще документация только на сайте онлайн, а у шестых — только оффлайн, в pdf, и не покрывает функционал полностью — копайся в сырцах, это же тебе надо.
                                                0
                                                Это ещё что, а вот регистрозависимость аргументов… Правда это уже про обычную консоль, не относится именно к git.
                                                  +1
                                                  Практически все консольные утилиты при запуске с ошибочными параметрами указывают ключ, по которому можно получить справку. Я, во всяком случае, с ходу исключений вспомнить не могу.

                                                  Так что запускаем утилиту с ключом --help и получаем либо справку, либо имя параметра для получения справки. Угадывать не нужно.
                                                +13
                                                Знаете что меня убивает в консольных утилитах? Чтобы ими пользоваться нужно постоянно иметь графический интерфейс в виде браузера с быстрым интернетом и сотней вкладок, где можно прочитать как что-то сделать в этой самой консоли. Да, если ты там делаешь одно и то же — можно и запомнить, но куда чаще приходится делать совершенно разные вещи единственный раз в жизни. Вот и выходит что пользуешься графическим интерфейсом (Google->Stackoverflow->мануалы) а потом руками переносишь это в консоль. Не самый эффективный метод.
                                                  +1
                                                  Готов подписаться под каждым словом.
                                                    +3
                                                    Обычно есть локальная справка. У привычки лезть за любой справкой в сеть есть и негативный эффект, особенно он наблюдается среди *nix пользователей в последние годы — люди вообще разучиваются пользоваться локальными man страницами и программами info/man в принципе.
                                                      +2
                                                      > он наблюдается среди *nix пользователей в последние годы

                                                      При этом надо не забывать, что программист — тоже пользователь. Сегодня человек как пользователь не читает маны, а завтра он как программист не пишет их. Например, вместо этого снимает видео урок и выкладывает на ютуб.
                                                        +2
                                                        обычно да, но:
                                                        1. листать ман в консоли и удобно браузить по десятку вкладок — две большие разницы.
                                                        2. чтобы почитать локальную справку нужно хотя бы знать какой утилитой пользоваться а затем её установить, если её нет. Чтобы понять что и как устанавливать — нужен браузер.
                                                        3. некоторые утилиты имеют гигантское количество параметров и опций, и вам возможно придется просмотреть их все, вместо того чтобы найти в браузере готовое решение своей задачи
                                                          0
                                                          1. Очень удобно, у меня часто два окна консоли рядом: одно с маном, в другом команду пишу. Какой браузер?

                                                          2. Чо? А чтобы найти подходящую графическую утилиту — браузер не нужен? А уж установить — ну хватит, apt-get install или emerge или yum и всё. Кстати, так вообще и утилиту поискать можно, часто даже находится, браузер оказывается не нужен.

                                                          3. Команды с гигантским числом параметров обычно рассчитаны на какие-то менеджеры для автоматизированного запуска. Например, gcc имеет очень дофига параметров, но вообще обычно руками его не вызывают, а используют make.
                                                            0
                                                            2. Нужен конечно, это и есть использование графического интерфейса, которое я предпочитаю консоли.
                                                            Кстати, так вообще и утилиту поискать можно, часто даже находится, браузер оказывается не нужен.
                                                            это как?
                                                              +2
                                                              Например, apt-cache search
                                                                0
                                                                Какая древняя магия :)
                                                              +1
                                                              С таким же успехом можно иметь перед вместо «мана» графический интерфейс.
                                                              К тому же я например программист для встраиваемых систем. у меня перед глазами часто кроме IDE для программирования микроконтроллеров ещё мануал по MCU, пара мануалов по чипам, работающим под управлением микроконтроллера, и AltiumDesigher Мне только ещё консоли с мануалом не хватает. У меня и так на столе три монитора стоит — на третий виртуальный осциллограф выведен.
                                                              +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. некоторые утилиты имеют гигантское количество параметров и опций, и вам возможно придется просмотреть их все, вместо того чтобы найти в браузере готовое решение своей задачи

                                                              Для этого есть поиск по локальной справке, в том числе нечёткий.
                                                              0
                                                              Предполагаю, это потому, что нет действительно хорошей документации по первоначальной работе с Linux. Небольшой, до 100 страниц, где бы описывались возможности стандартных утилит, их предназначение, какие-то широко используемые технологии и подсистемы (DKMS, systemd).

                                                              Вот, например, для тех, кто не любит читать маны в консоли, есть опция -H, которая сгенерирует HTML и откроет его в браузере.
                                                              man -Hfirefox 2 open
                                                              Или, например, если у вас есть какая-то объявленная через define константа в C-коде, но вы не знаете, какой заголовочный файл вам подключить, можно выполнить полнотекстовый поиск по man'ам:
                                                              man -K O_DSYNC
                                                              Как об этом узнать, не читая man man целенаправленно?

                                                              cc: merlin-vrn, Cheater
                                                                0
                                                                Вот, например, для тех, кто не любит читать маны в консоли, есть опция -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
                                                                
                                                                  –1
                                                                  Никак. И не нужно. Хочешь использовать все возможности — прочитай весь ман. Потом решай, что из этого тебе нужно.
                                                                    0
                                                                    А что делать, если вы не знаете, какой ман читать? Вот, например, вы просто не знаете о команде «man», или знаете, чего вам нужно добиться, но не знаете о конкретной утилите, которая сделает это.
                                                                      0
                                                                      man man
                                                                    +1
                                                                    > Как об этом узнать, не читая man man целенаправленно?

                                                                    Никак =) Вроде бы такого канонического документа «по общим вопросам» нет.
                                                                    Самое близкое, что я знаю, — это проект tldp.org. Но, как правило, по конкретной утилите или системному компоненту в интернете всегда можно быстро найти хороший вводный курс. Я сам грешен тем, что вместо мануалов порой гуглю быстрые howto от сторонних авторов.
                                                                  +2
                                                                  куда чаще приходится делать совершенно разные вещи единственный раз в жизни.
                                                                  Странно, мне, наоборот, куда чаще приходится делать весьма небольшое подмножество вещей.
                                                                  В случае с git это init / add / commit / push / pull / rebase / merge / diff / difftool / mergetool / reset / cherry-pick.
                                                                  Синтаксис запоминается довольно быстро, в крайнем случае есть локальная справка.
                                                                +2
                                                                Это нужно, когда вы работаете в одной ветке и в ней все в беспорядочном состоянии, а нужно срочно переключиться на другую ветку.

                                                                Вот никогда этого не понимал. Сделай коммит локальный, можно --amend прикрутить. Не хочешь забыть изменения — сделать коммит а потом резет, изменения снова станут показываться.
                                                                Куда хуже когда изменения из стека внезапно применяются не туда. Без всяких мержей.
                                                                  +1
                                                                   Сделай коммит локальный, можно --amend прикрутить. Не хочешь забыть изменения — сделать коммит а потом резет, изменения снова станут показываться.

                                                                  да, или stash. небось руки не отвалятся.

                                                                    0

                                                                    Также обратный случай, иногда начинаю фиксить в неправильной ветке. С git checkout легко просто переключиться на правильную, все изменения останутся на месте. Тут Gitless поступит как проще для новичка, но при этом лишаешься гибкости.

                                                                      0
                                                                      Тоже сначала про это подумал.
                                                                      Но там на скрине про бранчи есть коммент внизу, мол, можно протащить все с собой, добавив флаг.
                                                                      0
                                                                      Это нужно, когда вы работаете в одной ветке и в ней все в беспорядочном состоянии, а нужно срочно переключиться на другую ветку.
                                                                      А почему бы не вытащить исходники другой ветки в отдельную папку и в ней спокойно работать?
                                                                      +2
                                                                      [irony]Они сделали из гита меркуриал![/irony]

                                                                      Ну, вообще, я не знаю. Когда перешел с меркуриала на гит, первые несколько дней, конечно, плевался и чертыхался, но потом и сам не заметил, как привык. Просто надо понимать, как гит устроен — тогда и с командами проблем не будет. Ну, да, гит достаточно «низкоуровневый», но в этом есть и плюсы.
                                                                        +3
                                                                        На примере Gitless становится очевидно, что подход упрощения возможно применять и к другим сложным системам. Например, Google Inbox и Dropbox.

                                                                        Нет, это как-то совсем не очевидно. И что не так с инбоксом?


                                                                        ps

                                                                        Если вывод не придумывается, можно и без него.

                                                                          0
                                                                          Похоже автор имела в виду, что Google Inbox и Dropbox — ещё два примера применения упрощения сложных систем.
                                                                          P/S тоже сначала не мог понять, что не так с инбоксом.
                                                                          0
                                                                          > на научном подходе
                                                                          А где наука? Чем это лучше git + alias? Или опять сидеть алиасы перепиливать, но уже под Gitless? Скажите честно, учоные, это чей-то бакалавр «на отвались»?
                                                                            –28
                                                                            Все ходят вокруг этого git с такими умными лицами, будто это нечто гениальное! Эй, люди, опомнитесь — это писал тот же троечник, что наковырял Линукс! Причём написал git ДЛЯ СЕБЯ (ну и for fun, конечно! :) ). С чего вы вдруг решили, что ЭТИМ можно пользоваться для серьёзных продуктов?
                                                                            В мире тысячи команд, в каждой своя культура и способы работать сообща. То, что один очкарик мержит себе в линукс патчи, ещё не делает софт УДОБНЫМ и непротиворечивым. Собственно, потому Mercurial и применяется не менее широко, что сделан по-человечески.
                                                                              +7
                                                                              Git задумывался как «тупой трекер контента», и реализовывался соответственно. Но внезапно стал фактически отраслевым стандартом, обойдя всех конкурентов (можете погуглить современные рейтинги систем контроля версий — раз, два). И это при достаточно невменяемом интерфейсе, от которого плюются все новички.
                                                                                0
                                                                                Что за формулировка «трекер контента»? Насколько мне известно, он задумывался как удобное средство для управления патчами к linux.
                                                                                  0
                                                                                  Ну а чтобы составить патч — нужно знать, что включить в этот патч, т.е. нужно «трекать контент».
                                                                              0
                                                                              Вот, что бывает когда гуманитарий берется за рассуждения над сугубо техническими деталями…

                                                                              100% вопросов и недостатков git обсуждаемых выше решается надстройками — gui интерфейсами вроде tortoisegit и веб версиями вроде github.

                                                                              Остальное — велосипеды с квадратными колесами, на 99% копирующими оригинал(в том числе логику\исходные коды) с ничтожными изменениями, в надежде «выехать» на этом.
                                                                                –4

                                                                                Ну а родовую травму гита с коммитами не привязанными к веткам они побороли? А то все эти костыли с добавлением имени ветки в сообщение коммита, через хук порядком надоели.

                                                                                  0
                                                                                  На какие только извращения люди не идут ради того, чтобы не читать документацию.
                                                                                    +9

                                                                                    на какие только уловки не идут люди, лишь бы не менять мнение

                                                                                    +4

                                                                                    Странно, что умолчали о замене интерактивным командам git, типа git add -i, git rebase -i.
                                                                                    Я вообще без них workflow в git не представляю.

                                                                                      +1
                                                                                      > git checkout < file > // отбросить все изменения в одном файле с последней выгрузки в систему
                                                                                      > git reset --hard // отбросить все изменения во всех файлах с последней выгрузки в систему

                                                                                      > Две разные команды для одной функции с одной разницей в том, что одна для одиночного файла, а вторая — для множества файлов.

                                                                                      Команда для отбрасывания изменений во многих файлах или в целом каталоге проста и логична и ничем не отличается от отбрасывания изменений в одном файле: git checkout file1 file2 dir3 dir4… То, что другие команды (например git reset --hard или git checkout -f) способны произвести тот же эффект, не значит, что «в гит изменение в одном файле откатывается одной командой, а изменение во всех файлах — другой!11». В общем, кто-то ниасилил git checkout --help.
                                                                                        +3
                                                                                        Разработчики, которые пользуются системой, ее или любят, или ругают за сложный интерфейс и баги.

                                                                                        За какие это баги ругают git?

                                                                                          0
                                                                                          Я думаю имелось ввиду, что некоторые операции в git заведомо опасны и могут необратимо сломать локальный индекс. Это сделано не зря, поскольку для больших проектов (в первую очередь ядро Линукс) это необходимо, но для новчиков это минное поле: нашел инструкцию в интернете, ошибся, клонируйся заново. На StackOverflow это распространненый класс вопросов по git.
                                                                                            +1

                                                                                            Из личного опыта (под Windows):


                                                                                            1. В какой-то версии, ещё в 2012 году, вместо системной кодировки (cp1251 которая) имён файлов стала использоваться UTF-8. Репозиторий пришлось конвертировать, благо на тот момент мы git серьёзно не использовали (в hg подобная проблема, кажется, и позже была, но только при переходе linux<->windows).
                                                                                            2. Где-то год назад git перестал адекватно воспринимать старые DOS-овские имена наподобие ABC~1.TXT (закрыли какую-то уязвимость). Были проблемы с добавлением/удалением/checkout-ом этих файлов, то есть файл был отмечен как изменённый, и ничего с этим поделать нельзя. Переименовать тоже просто так нельзя.
                                                                                            3. Регистрозависимость имён файлов. "Любимый" баг. Git на Windows и сегодня не подозревает, что ABC и abc — одно и то же. Если где-то в диффе изменений встречается переименование ABC->abc, git при слиянии этих изменений в другую ветку не может сделать это переименование, и в дереве файлов появляются оба. А затем — проблемы с checkout-ом и с удалением "лишних" файлов.

                                                                                            Не уверен, что ругают именно за эти баги, но проблемы бывают.

                                                                                              0
                                                                                              Еще бывает, когда есть сразу 2 файла ABC и abc. Висит один измененный файл, через stash не убирается, ни merge ни rebase не сделать. Исправить можно, если отключить в реестре флаг obcaseinsensitive, примонтировать диск в cygwin с опцией posix=1, и сделать git reset --hard в git, установленном из репозиториев cygwin.
                                                                                                0

                                                                                                Проблемы бывают у всех, но "ругают за баги" подразумевает, что программа глючная и пользователи постоянно сталкиваются с проблемами. В случае гита, это не так.

                                                                                              0
                                                                                              Ну да, ломать — не строить. Для отдельного файла можно отдельную ветку сделать. Может быть я в чём-то не прав, но по-моему самого базового функционала git уже за глаза, если аккуратно его использовать. А дезть в дебри — усложнять себе работу.
                                                                                                –1
                                                                                                Это MIT, эти парни не могут ошибаться! Если NIH разработка имеет солидный бренд, то это наверняка очень крутая штука.
                                                                                                  0
                                                                                                  На примере Gitless становится очевидно, что подход упрощения возможно применять и к другим сложным системам. Например, Google Inbox и Dropbox.

                                                                                                  Что сложного в этих системах?
                                                                                                    0
                                                                                                    Промптом переводил?
                                                                                                      0
                                                                                                      Да, «область стадий» мощно перевели))
                                                                                                      0

                                                                                                      1) А почему не указано что перевод?
                                                                                                      Вот, честно, обсмотрел везде со всех сторон пост и не нашёл плашки перевода. Опять замечательные улучшения интерфейса от ТМ или её и вправду нет?


                                                                                                      2) Пока читал, то и дело возникал баттхёрт от непонимания автором (кем бы он ни был) ни специфики работы vcs, ни конкретно git'а, ни даже что какие команды делают.


                                                                                                      ИМХО, такое чтиво вредно для здоровья.

                                                                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                      Самое читаемое