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

    Предупреждение: Эта статья вас ничему не научит. Это очень высокоуровневый взгляд, мои мысли, моя рефлексия на вопрос, который для меня важен + небольшое этнографическое исследование по графическим клиентам git-а.

    Поговорим о распределенных системах управления версиями.

    CVS был грустным, медленным, неатомарным („ничего не трогайте, я коммичусь“), зато с нормальным клиентом в Эклипсе.

    SVN был медленным и поначалу веселым, но с появлением первой ветки тоже грустным („ничего не коммитьте, я мержусь“), с двумя разными клиентами в Эклипсе, баги которых нежно дополняли друг друга.

    Тогда я выучил git. Git — это такой нелогичный набор утилит командной строки, в котором ежедневные операции выполняются последовательностью из двух–четырех команд. Первую неделю я тыкался в каждый угол, как слепой щенок. Я рисовал себе схему четырех хранилищ (working copy, staging area, local repo, remote repo), и подписывал стрелочками, какая команда и с какими опциями переносит информацию откуда куда. К концу этого периода адаптации я нащупал те заветные комбинации, которые мне нужны были в повседневной работе, и обрел некоторую смелость в перетасовке набора команд с листочка, заставляя их выдавать более-менее то, что мне нужно. Силу интерактивного коммита из коммандной строки, или, допустим, какие делать запросы, чтобы понять текущее состояние, я не освоил до сих пор. Порадовало, что репозиторий можно вертеть как угодно, пересвязывать что угодно с чем угодно, правда, магия для этого нужна соответствующая.

    Недавно познакомился с Меркуриалом — тут я даже не пытался ничего учить, сразу графический клиент поставил, пожалел свой мозг. Почитал, как у них переписывается история, чтобы сделать commit amend — это ритуал с тремя получасовыми заклинаниями и одним „расширением“ (установка расширения заключается в том, что ты в конфиге прописываешь его название — типа до этого Меркуриал ничего о нем не знал, а теперь вот узнал). Изучить оба этих инструмента одновременно — ну я не знаю, кем надо быть:



    „К чему это я веду?“ — спросит нетерпеливый читатель. Порог вхождения в РСУВ (DVCS) высок. Многие не пользуются ими не потому что думают, что это им не нужно, а потому что это на самом деле сложно. В том числе программисты, которые в большинстве своем тоже люди. Сами создатели больше внимания уделяют внутрненнему устройству, чем командному интерфейсу — ну так где же сторонние разработчики, где энтузиасты? Такой сложной вещи, как управление репозиторием, прямо просится, ну напрашивается же графический клиент! Их есть немало. Я посмотрел на маковский сектор — казалось бы, для людей должны делать.

    Первый печальный факт заключается в том, что подавляющее число клиентов только и умеет, что показывать дерево и коммитить. Это уже кое-что — можно, по крайней мере, понять состояние репозитария, но в остальном означает, что чуть-чуть за границей прямолинейной истории коммитов ты опять останешься один на один с командной строкой.

    Второй печальный факт заключается в том, что даже показать дерево они нормально не могут — хотя, казалось бы, ну если у твоей программы две функции, ну хоть их-то вылижи основательно.

    К примеру, старый gitk прикладывал немало усилий, чтобы запутать своего пользователя:



    Такой подход оправдан в случае Виндоуса и Линукса (а как иначе продавать поддержку?), но здесь вызывает вопросы.

    На сегодняшний день (1.7.3.5) gitk немного исправился, но картинка все еще не способствует считыванию информации — цвета распределяются по непонятному алгоритму и вообще отвлекают, надписи не выровнены, что затрудняет сканирование:



    Но! Самое интересное, что они на этом не остановились. По умолчанию gitk показывает историю в… барабанная дробь… перепутанном виде! Это у них зовется „нестрогая история“ или как-то так. Жму руку, наверное. Предполагается, что это должно упростить восприятие:



    И, что характерно, пример подхватили (про это см. также третий печальный факт). Вот, например, пафосный Tower, который дерево рисовать вообще не любит (я его даже не сразу нашел — обычно у него там просто список коммитов размером на полэкрана a la github):



    Вот gitx, не такой пафосный и реально с двумя функциями. Они, как и авторы gitk, решили сэкономить десяток-другой пикселей на левом крае в ущерб читаемости. И gitx, и предыдущий Tower дерево „строгой“ истории показывать вообще отказываются.



    А вот egit, Эклипсовый плагин, для которого не то что дерево, для него надпись некриво нарисовать проблема. Я к этому был готов, но вот своим оригинальным видением он меня удивил:



    Неожиданно неплохо показал себя SourceTree. Дерево у него не лишено самопересечений, но зато суть происходящего не скрыта за месивом кружков и линий.



    Мне он очень нравится, но опыт показал, что создать мерж из него, например, не получается. Поэтому только для тупых задач. Зато умеет и git, и Меркуриал, не задает лишних вопросов (куда вы установили дистрибутив git-а?), но предугадывает правильные (имя и емейл для коммитов).

    Я даже из интереса сделал свой вариант этого дерева:



    Цвета убраны, самопересечений нет, мержи выделены, т.к. это не полноценные коммиты (по сути, не по реализации) — это пока все, что я придумал полезного. Если кто-то может посоветовать еще что-то — буду рад.

    И, наконец, третий печальный факт. Есть клиенты, которые умеют чуть больше — наверное, руки дошли, успели. Но их „продвинутый“ функционал — это тот же самый набор консольных утилит, для которых просто есть кнопочки в интерфейсе.



    Никто почему-то не додумался до простой мысли, что на основе того конструктора, того АПИ, который представляют собой git и hg, можно и нужно делать удобный, простой и понятный интерфейс, с новыми метафорами, действиями, возможностями; интерфейс, убирающий недостатки, а не повторяющий их; но все как один раз за разом повторяют то, что от бессилия наклепали авторы консольного интерфейса. Я настаиваю, что сегодняшние РСУВ — это не готовые к использованию продукты, а платформы, которые пока еще только ждут своего продукта.

    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 134
    • +8
      1) А я обычно работаю с hg через консоль, даже если редактирую исходники через IDE с поддержкой hg.

      2) Про последние замечания: если в IDE будут свои термины и свои методы работы с репами, то людям, уже знакомым с нужной DVCS, будет только больше головняка. Помню как я подвисал в netbeans, пытаясь понять, что значат те пункты меню, которые не совпадают с терминами hg.
      • +1
        а я в емакс воткнул всеже…
      • +1
        Тоже через консоль работаю, но иногда использую diff merge в качестве внешнего diff.
        • 0
          Я тоже очень часто работаю с git в консоли, хотя когда подключил к Emacs-у magit — начал потихоньку забивать. Основная причина — из magit значительно удобнее стейжить отдельные файлы.

          Автору:
          К git в больших проектах следует относится скорее не как к системе контроля версий, а как к конструктору любой системы контроля версий. В зависимости от предпочтений и стиля разработки, к нему можно один раз написать набор скриптов, покрывающих весь development routine, и больше не вбивать одни и те же комманды по несколько раз.
        • +2
          Svn+eclipse — для меня слишком удобно, чтобы пытаться изучать и привыкать к чему-то еще. Заморачиваться с выбором инструмента контроля версий — выше моих сил.
          • 0
            сочувствую
            ладно вы не видели Idea, но вы даже TortoiseSvn не видели
            svn в эклипсе — в некоторых случаях даже командная строка удобнее
            • 0
              А большая команда разработки, в которой вы состоите? Если состоите, конечно.
              • +1
                5 человек, код которых может пересекаться при коммите, 40 человек всего.
            • +3
              Статья похожа на перевод :) А так да, почти все по дело, хотя по-моему у Меркуриала все не так плохо. По-крайней мере все каманды вполне логичны.
              Опять же Backout и Strip ревизии у меня никогда не вызывали проблем(commit amend == Backout так ведь?)
              Но, таки да, вот такие вещи в истории убивают:
              habrastorage.org/storage/3449db33/2f7fc601/3d3dca21/03eedec2.png
              Но можно упростить, включив Compact Graph
              habrastorage.org/storage/ff20f07c/44683672/498bfc41/84de1220.png
              Блин, картинки не вставляются.
            • 0
              их „продвинутый“ функционал — это тот же самый набор консольных утилит, для которых просто есть кнопочки в интерфейсе
              естественно. ведь libgit нет и не предвидится (за исключением dulwich).
              • 0
                А разве в самом git-е внутри не набор гибких низкоуровневых утилит, с помощью которых можно делать с репозиторием что угодно?
                • +6
                  Можно-можно. Это если
                  а) разобраться, что делает каждая из них
                  б) разобраться, какие команды и в каком порядке вызывать
                  в) разобраться, почему именно в таком порядке
                  г) разобраться, что вызывать, если что-то пойдёт не так
                  д) во всех предыдущих пунктах — курить ключи форматирования вывода на предмет сделать его пригодным для парсинга и парсить-парсить-парсить stdout+stderr. Другого пути нет в принципе (не считая помянутого dulwich).
                  Inb4: нет, это никакой не unix-way, дорогие фанбойчики. Это самый что ни на есть кровавый enterprise эпохи CP/M и MS-DOS.
                  В случае с mercurial можно хотя бы на питоне сказать import hg и жонглировать репозиториями в хвост и в гриву. Даже всеми гонимый svn есть фронтенд к libsvn, которую, к слову, и используют всяческие фронтенды (к слову, libчтототам + пачка фронтендов — это и есть unix-way).
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • 0
                      dulwich не требует установленного git. git-python — требует
                    • 0
                      JGit
                    • +3
                      я вот бы с удовольствием послушал рассказ парней из JetBrains о том, как они приручали эти «гибкие низкоуровневые утилиты», когда писали поддержку Git в IDEA сотоварищи
                      • 0
                        ого. ну тогда ок.
                        • 0
                          Странно, правда, только вот что —
                          а) почему её не используют Торвальдс сотоварищи?
                          б) почему её нет в репозиториях?
                      • +4
                        Почитал, как у них переписывается история, чтобы сделать commit amend — это ритуал с тремя получасовыми заклинаниями и одним „расширением“
                        попривыкали, панимашь, историю править со своим гитом.
                        установка расширения заключается в том, что ты в конфиге прописываешь его название — типа до этого Меркуриал ничего о нем не знал, а теперь вот узнал
                        установка — это sudo pypi-install mercurial_keyring. а «прописать в конфиге» — это включение. так, знаете ли, существенно гибче, ЕВПОЧЯ.
                        • +3
                          Мне как пользователю хочется пользоваться. Пусть при первом вызове расширения он его сам скачает, установит и включит.
                          • –1
                            с данными запросами — в багтрекер, будьте любезны.
                            • +1
                              Расширение уже входит в комплект и ничего скачивать и устанавливать не надо. Просто оно отключено по умолчанию.
                          • +3
                            так на самом деле и не понял, почему git — «нелогичный набор утилит командной строки».
                            это похоже на то, если бы я жаловался на vi — «как это можно столько команд запомнить? как-то все непросто… и GUI нет? кто ж будет в консоли код редактировать?»
                            по-моему, git — очень удобный инструмент, всегда работаю с ним только из консоли, ничего лишнего, как и все профессиональные инструменты — мощь и простота в одном.
                            • +2
                              Потому что перемещения между четырьмя хранилищами (к примеру):
                              а) каждое называется своим словом, причем в него не входит имя хранилища,
                              б) некоторые разные перемещения выполняются одной командой + аргументы, в которых опять-таки не учавствует имя хранилища.

                              То есть, чтобы этим рулить, надо запомнить эн несвязанных слов и их соответствие реальности. Это я называю нелогичностью. Интерфейс поверх — чтобы не запоминать, чтобы не лазить в ман.

                              В vi все нормально — его текстовость ему не мешает. А в такой сложной визуальной штуке, как репозиторий, было бы более к месту непосредственное оперирование деревом, драг-унд-дроп какой-нибудь.
                              • +2
                                честно, ничего не понял…
                                примеры для а) и б) можно озвучить?
                                репозиторий необязательно должен быть визуальным, есть best practices в программировании, есть подобное и в организации работы с репозитариями. если следовать хотя бы некоторым из них — совсем необязательно «видеть» все дерево и оперировать на нодах.
                                • +1
                                  Вот примерно:


                                  Я лично системы в этих командах не вижу. Просто эн слов. И тут еще не затронуто перемещение по дереву.
                                  • 0
                                    соглашусь лишь с тем, что из этой диаграммы мало что можно понять, лишь глядя на нее. хотя если разобраться, то все верно. просто неудачная диаграмма, мне кажется — это лишь пример работы с git.
                                    • +1
                                      Нет-нет, это как раз удачная! Неудачная — это что-то типа

                              • 0
                                Полностью согласен с вами, также работаю с git — очень удобно, особенно когда нужно переносить проекты с компа на комп через флешку. Также работаю и c hg, но после git чуствую себя не в своей тарелке.
                                • 0
                                  вот такой оффтопичный вопрос
                                  почему добавление в staging называется git add filename, а удаление оттуда git rm --cached filename.

                                  Или есть другой вариант?
                                  Как заанстеджить все файлы? А все файлы соответствующие маске?
                                  • 0
                                    for i in `git status --porcelain | grep '^D.*\.foo$' | sed 's/^D \+//'`; do
                                        git reset HEAD "$i"
                                        git checkout "$i"
                                    done
                                    

                                    для файлов по маске *.foo
                                    • 0
                                      найдено в stackoverflow если что, мне пока что не приходилось с подобным сталкиваться. если не секрет — в svn это делается проще?
                                      • 0
                                        да я вот тоже находил это на stackoverflow, но сомнительное решение

                                        особенно если учесть что git add dir/subdir может загрести пару временных файлов случайно и их хочется так же легко и непринужденно убрать из staging.

                                        в svn — если мне не изменяет память svn checkout?
                                        • 0
                                          git checkout PROJECT_NAMEl/*.java
                                          

                                          только что сработал
                                          • 0
                                            равно как git checkout. для всех файлов
                                            • 0
                                              хотя нет, unstage — противоположность add? тогда reset только индексы изменит. да, не приходилось добавлять и удалять много файлов за раз.
                                          • +1
                                            не поймите неправильно, мне нравится гит, но хочется его использовать как-то эффективнее что ли, уловить стройность команд и аргументов, как к примеру приходит понимание Perl-а
                                            • +1
                                              я с svn загнул потому что в svn вообще нет staging :)
                                          • 0
                                            Воспользоваться GUI? :)
                                            • 0
                                              да, можно использовать git add -i
                                              это практически GUI, почитал книжку и наверное теперь только им и буду пользоваться
                                              • 0
                                                Можно и из консоли, да.
                                        • 0
                                          было бы интересно увидеть предложения по возможному интерфейсу для git или hg.
                                          Сам далеко не на всю использую гит — больше для синхронизации локал репозитория с продакшеном — ни о каких слияниях не ведаю.
                                          • 0
                                            Предложения-то есть, но их много. Как будут оформлятся, буду держать хабр в курсе. Это только начало пути. В конце, надеюсь, всем станет хорошо.
                                          • +2
                                            Пробовал использовать gui-ные клиенты, в частности для git / hg. Всё такое непонятное, по-моему в консоли в данном случае проще и быстрее работать. Скажем, hg sum --remote опишет весь статус дерева в простой и лаконичной форме, чтобы получить столько же информации из окна программы, в него нужно две минуты смотреть.
                                            • 0
                                              Ха-ха, 5 баллов! Первая часть с описанием систем — именно так, как все и есть. Пока сижу на SVN, как-то привык, во всяком случае с логами не так запутанно как в git'е. Да и tortoisesvn помогает. Наверное, надо тоже выписать git команды на листочек. :)
                                              • 0
                                                Qgit — такой же кошмар, как и всё остальное, описанное тут. Проще в GitHub'е посмотреть, что где.
                                                • –3
                                                  Да что ж все так с этим Git носятся… SVN нормальная система, пользуемся ей при разработке (клиент интегрирован в Zend Studio) — вопросов никаких — всё нормально… зачем париться и переводить всех на Git, если есть SVN?
                                                  • 0
                                                    каждому свое, как говорится. почему же люди переходят со старых систем на новые? сам Торвальдс отвечает на многие вопросы о гит. хотя бы вот это видео посмотрите (на русском) www.youtube.com/watch?v=BtAlN4MaBr8
                                                    • 0
                                                      а) локальные коммиты + редактирование коммитов перед пушем.
                                                      б) локальные ветки.
                                                      в) нет проблем с мержем (в svn при отделении ветки обратно ее можно смержить только один раз, что ли. А практика показала, что там еще какие-то странности вылезают).
                                                      г) ну и скорость.
                                                      д) работа в оффлайн еще, иногда.
                                                      • 0
                                                        Вот еще замечательный ответ от deeGraYve. Я, честно говоря, уже и забыл, что в svn всего этого нет :)
                                                        habrahabr.ru/blogs/development_tools/112648/#comment_3609048
                                                      • +2
                                                        Порог вхождения в РСУВ (DVCS) высок. Многие не пользуются ими не потому что думают, что это им не нужно, а потому что это на самом деле сложно. В том числе программисты, которые в большинстве своем тоже люди.

                                                        Пару консольных команд программистам выучить сложно да понять структуру репозитория, основанную на обычных деревьях? Я считаю, что таких людей вообще можно не относить к программистам.
                                                        • +1
                                                          для меня ваши слова звучат как «программистов в виндусе не бывает»

                                                          ну просто в виндусе консоль настолько убогая, что ею стараешься не пользоваться никогда
                                                          • 0
                                                            есть же mingw )
                                                            • 0
                                                              да, кстати, в стандартной консоли cmd.exe работать тяжко, видел как это делают, получается всё очень медленно… я работаю через Far + иногда через кнопки в editplus, очень редко через netbeans
                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                              • +1
                                                                Окей, давайте поставим вопрос так: почему git/hg сделаны так, что ими могут пользоваться только программисты?
                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                  • 0
                                                                    Хорошо, почему тулзы, которые нужны не только программистам, рассчитаны только на программистов?
                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                      • +2
                                                                        Нет, я из тех, кому „Пару консольных команд… выучить сложно“. Ну и дизайнеры — они не люди? Технические писатели?
                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                          • –1
                                                                            Глупо-не глупо, но так работает прогресс.
                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                          • 0
                                                                            Необязательно технические писатели, любые: чем пользоваться им? Особенно, если творчество коллективное. Движками вики, другого ничего не остаётся подходящего обычным пользователям — не программистам?

                                                                            Но вики не годятся для предпечатной подготовки. Чем пользоваться редактору/редакции при подготовке книги к печати, а именно для отслеживания процессов вёрстки и корректуры-вычитки?

                                                                            Скрибус, как я понимаю, имеет бинарный формат и потому не прикручивается к системам контроля версий, TeX/LaTeX и сам по себе по юзабилити убойный, а если ещё надо объединить с системой контроля версий, то вообще ппц, неспецы не осилят.
                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                              • +1
                                                                                > Для коллективного использования есть издательские системы

                                                                                Какие? Adobe и QuarkXPress? Группа, к примеру, учёных должна ставить себе этих монстров, чтобы совместно написать статью или учебник? Я уж не говорю — покупать за деньги. Я, кстати, не уверен, что с управлением версиями там и коллективной работой там всё есть, что нужно.

                                                                                Средства, как бы имеющиеся в MS Office или Open Office, для коллективной работы не годятся, ибо крайне убоги. А для предпечатной подготовки эти программы тем более не предназначены.

                                                                                > Для остальных вот

                                                                                И что — вот? Там нет ничего подходящего. Видно, что Вы сами не копали. К сведению: поиском по интернету я пользоваться умею.

                                                                                > Бинарный формат сам по себе не помеха использования VCS просто текст-ориентированные системы с ними теряют смысл. Но историю хранить можно.

                                                                                Вот именно, что теряется смысл.
                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                      • 0
                                                                        Вы еще спросите, почему все IDE, а также emacs и vim сделаны так, что ими могут пользоваться только программисты.
                                                                        • 0
                                                                          IDE весьма успешно пользуются и не-программисты в вашем понимании, например я.
                                                                    • +4
                                                                      Исренне не понимаю, что сложного. Сам пользовался SVN и Hg (под Windows, из клмандной строки и с Tortoise* клиентами), за несколько дней осваиваешь, коммит — апдейт — пуш/пулл — просмотр истории, все элементарно и понятно. Все изменения в файле подсвечиваются разными цветами, очень просто.

                                                                      Или вы ветки/теги создаете, форки и мержи делаете? Ну так либо освойте магию командной строки и силу воображения, либо мучайтесь дальше, Буратино вы наш. Это кунфу отнюдь не для людей, неспособных на что-то более сложное, чем «плагин к эклипсу» (хотя я сам не очень понимаю, зачем все эти сложности вообще нужны).
                                                                      • 0
                                                                        Вы, видимо, не поняли. С Гитом у меня все прекрасно, я его освоил, именно из командной строки. Но мне не нравится это положение вещей. Или вы из тех, кто считает, что серьезные вещи обязательно должны делаться сложно?
                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                      • +3
                                                                        Чёрт, среди множества людей, большинство из которых почему-то стремятся к усложнению, очень редко встречаю человека, который стремится к ясности и простоте.
                                                                        Виват!
                                                                        • 0
                                                                          git — ясно и просто
                                                                          • 0
                                                                            минусующих прошу объяснить чем checkout, merge, pull (--rebase), branch сложны и почему ими нельзя пользоваться?
                                                                            • +2
                                                                              Я склонен согласиться скорее с собственными наблюдениями и аргументацией в статье выше, чем с вашим, не слишком аргументированным, заявлением.
                                                                              Фразы вроде «гит — это просто» или «а что не так в линуксе с отрисовкой шрифтов?» вызывают во мне такой взрыв негодования и справедливой аргументации, что я, пожалуй, лучше промолчу.
                                                                              • –2
                                                                                простите, ниже напишу более аргументированно.
                                                                                в вашем, тоже далеко не самом аргументированном, ответе вы говорите об аргументации в статье. я увидел только два «аргумента» — GUI клиенты не умеют делать ничего, кроме отрисовки структуры и коммита, и то, что они делать не умеют.
                                                                                не соглашусь с обоими — 1) есть proprietary клиенты для гит, которые могут больше, чем простой коммит (этой системой моя компания пользуется внутри, но я все-таки предпочитаю консоль) 2) «правильной» отрисовки не существует, потому как разным людям нравятся разные стили.
                                                                                другого в статье не увидал, увольте, давно в России не был, быть может что-то пропустил. я уже писал выше, что так и не понял примеры про перемещения и хранилища автора статьи, он пока что мне не ответил.
                                                                                уфф, передохнуть надо, давно я по-русски столько не писал, ниже отвечу, почему мне кажется, что гит — ясно и просто.
                                                                                • +6
                                                                                  все нижесказанное — мое личное мнение
                                                                                  1) гит ясен прежде всего своей структурой — разветвленная дерево-подобная цепочка коммитов. вся история создания продукта — как на ладони, никто не боится создавать дополнительные ветки, разработчики не наступают друг другу на ноги — у каждого своя ветвь. в svn все время боялся создавать новые ветки, потому что merge двух веток — жестокое упражнение, которое нужно было планировать заранее, чтобы никто во время мерджа случайно чего-нибудь там не обновил.
                                                                                  2) использование хэшей и тагов — любому программисту придутся по душе имена нодов, все уникальны, можно «перенестись в прошлое» без каких либо проблем
                                                                                  3) использование stash — невероятно удобно, если под рукой вертится кто-то, кто постоянно спрашивает, что да как происходит в master и какой-нибудь другой ветке (PM например) — не нужно суетиться и сохранять все то, над чем работаешь в данный момент (может оно и не компилируется вообще) — сохранить в stash и вернуться на исходную — одна комманда.
                                                                                  4) bisect просто незаменим, если работаешь в большой комманде и в день набегает по нескольку сотен коммитов — попробуй найди потом кто и когда закоммитил код, который что-то там сломал
                                                                                  5) git хранит полную историю — файлы, которые были когда-то давно добавлены и удалены, их можно вернуть когда угодно.
                                                                                  6) независимость от центрального репозитория — моя копия всегда хранит ВСЮ историю, из нее можно полностью восстановить репозиторий.
                                                                                  7) pull --rebase — очень удобен для слияния веток, если автоматически merge не происходит, rebase остановится, даст возможность вручную исправить код, rebase --continue продолжит merge, --abort вернет все на исходную
                                                                                  8) dry-run (для патчей --check) — предпросмотр, очень полезная штука, покажет где и почему произойдут ошибки merge
                                                                                  9) отсутствие бестолковых .svn папок — не люблю мусорить там, где работаю
                                                                                  10) cherry-pick — одна из моих любимых комманд, выборочно применяет коммит с определенным хэшем — легко проверить, что работает, а что нет.

                                                                                  я не агитирую никого за использование git, мне лишь непонятно то, почему люди им не пользуются. да, возможно, learning curve у него покруче остальных, но совсем необязательно пользоваться всеми коммандами гита, начинать можно с самых базовых, постепенно осваивая новые. это инструмент, прежде всего, как и у любого инструмента у него есть преимущества и недостатки, лично для себя его преимущества помогли мне стать намного эффективней, только и всего.
                                                                                  • +2
                                                                                    5) git хранит полную историю — файлы, которые были когда-то давно добавлены и удалены, их можно вернуть когда угодно.


                                                                                    Справедливости ради надо сказать, что это не совсем правда. В git вполне можно, при неосторожном обращении, потерять что-то важное.
                                                                                    Создаете ветку -> добавляете файлы -> удаляете ветку.
                                                                                    Все — ваши файлы буду жить до первого git gc.
                                                                                    В меркуриале, как я понимаю, ничего никогда не исчезает в принципе.
                                                                                    • +2
                                                                                      Ну… там можно сделать strip :)
                                                                                  • –2
                                                                                    и, на закуску, уже не МОЕ личное мнение — whygitisbetterthanx.com/
                                                                                    • 0
                                                                                      whybetterthanhg —
                                                                                      * Cheap Local Branching — mercurial.selenic.com/wiki/LocalbranchExtension
                                                                                      * Staging Area — не факт, что её наличие лучше. Ведь есть RecordExtension, crecord и выбор hunkов в tortoisehg
                                                                                      * Github — hg-git же. Причём с точки зрения юзера не меняется ничего, кроме урла репозитория.
                                                                                      …как, это всё?
                                                                                      • 0
                                                                                        я вроде упомянул, что это не мое мнение, на сайте есть disclaimer — можете написать Scott Chacon письмо, если вы не согласны, код сайта в открытом доступе в гитхабе. я про hg не знаю ровным счетом ничего, я даже спорить не собирался про то, чем лучше git, потому что уверен, что сколько людей — столько и мнений. а сайт написан человеком, который дал сравнение git с другими системами.
                                                                                  • 0
                                                                                    это вы про какой-то ещё не написанный git говорите. потому что mercurial определённо проще
                                                                                    • 0
                                                                                      «mercurial определённо проще» — это аргумент? я с mercurial не работал, уверен, что не все из здесь присутствующих с ним работали, так объясните, чем он проще.
                                                                                      • 0
                                                                                        Это впечатления. Я в своё время, попользовав git в течение полугода, освоил mercurial за… ну пусть будет за день подсматривания в первый попавшийся cheatsheet.
                                                                                        • 0
                                                                                          каждому — свое, просто я думал, что слово «определенно» несет за собой нечто большее, чем собственные впечатления. я вот своими поделился — про то, что гит «ясно и просто» — людям это почему-то не понравилось.
                                                                                • 0
                                                                                  Чуствую скоро будут священные между инструментами управления, как с языками программирования )
                                                                                  • –1
                                                                                    Уже есть, я уже пару раз холиварил на тему svn vs. git. Вот только никто так и не привел мне вменяемых аргументов чем гит лучше. Считаю, что и то и другое хорошая штука которой можно пользоваться, по крайней мере у меня за три года использования svn проблем не возникало.
                                                                                    • +1
                                                                                      У вас, наверное, просто относительно поступательная разработка.

                                                                                      Вряд ли у вас были задачи вроде: Support<A,B,C,trunk> = «работать над A на основе trunk, потом срочно разработать фикс B на основе trunk, подать B на тестирование, вернуться к A, дорабатывать, сделать исправления по результатам тестирования к B, подать B на тестирование, делать фикс C на основе trunk, зарелизить B, отдать на тестирование A, отдать на тестирвоание C, выполнять Support<D,E,F,B>, параллельно релизя A и C и мержа результаты вышеописанного процесса в trunk»

                                                                                      Сам пользуюсь git, при том, что основной репозитарий — svn и мержи приходится делать rebase`ами. Даже при этом удобство неописуемое — в описанном выше процессе не приходится постоянно заниматься конфликтами или молиться на svn`овский мерж, что бы он «не потерял» репозиторий.
                                                                                  • +4
                                                                                    В gitk я смотрю разноцветное дерево только для ощущения масштабности работы, никакого практического применения я ему не нашёл. В этом случае как раз большой плюс, что история запутанная и дерево получается развесистым, так оно сильнее внушает.
                                                                                  • +1
                                                                                    Согласен с тем, что изучить Git непросто. Но все становится гораздо очевиднее, если потратить немного времени на изучение внутреннего устройства репозитория. Могу посоветовать книгу Git Internals от Peepcode. Признаться, долго сокрушался и приводил в порядок свой первый репозиторий после ее прочтения ;)
                                                                                    P.S. Кстати, слышал мнение о том что некоторые другие DVCS, например Mercurial и Bazaar проще для понимания, но сам ничем кроме Git никогда пользовался (даже SVN), поэтому сравнивать не могу.
                                                                                    • +1
                                                                                      в случае с mercurial вам не нужно читать hg internals, чтобы понять, как с ней работать и почему именно так. честно-честно.
                                                                                    • 0
                                                                                      Пытялся смотреть в сторону других VCS, но в результате до сих пор на SVN. Он, конечно, медленный и печальный, зато простой и удобный. А медленность и печальность отлично лечатся SSD.
                                                                                      • +2
                                                                                        Это git и mercurial для вас сложные? Ничего IBM Rational ClearCase доберётся и к вам, вот тогда и поговорим о сложности.
                                                                                        А вообще Tortoise HG/Git достаточно упрощают интерфейс. Я за час обучил инженеров электронщиков, которые до этого ничем кроме проэкт21.01.2003.12.34.rar не пользовались и ничего освоили успешно и довольны и почему то не жалуются на сложность.
                                                                                        • 0
                                                                                          консоль лучше всего ;)
                                                                                          у меня вот так — snapplr.com/gpr1
                                                                                          • +1
                                                                                            IO_PURGATORY — это сильно
                                                                                          • +1
                                                                                            Странно, что среди нескольких gui-клиентов для git под mac не был упомянут SmartGit. Ведь весьма популярный и удобный на мой взгляд клиент.
                                                                                            • –1
                                                                                              Не всех покемонов я собрал, да.
                                                                                            • +1
                                                                                              Я так и не понял, о чём статья? О том, что все GUI фигово деревья рисуют? Или о том, что командная строка отстой? Напишите тогда ваше видение того, как надо работать с DVCS, у Mercurial есть API. Вы ведь не кричите, что вам стиральной машинкой пользоваться непонятно, а читаете инструкцию. Почему тут не хотите? Вы же программист, а не дитё малое.
                                                                                              P.S. TortoiseHG.
                                                                                              • 0
                                                                                                Короче смысл статьи в том, что DVCS — это немного сложнее, чем VCS. Плюс у DVCS еще достаточно плохо проработаны гуевые тулзы.

                                                                                                Что касается TortoiseHG, мне не нравится в нем одно: у него все окошки сильно отличаются от TortoiseSVN, которым я пользовался несколько лет и к которому привык. Когда приходится иметь дело и с hg, и с svn (в некоторых проектах до сих пор сидят на нем), то бесит переключаться между одним GUI и другим.
                                                                                                • 0
                                                                                                  Я думаю, что человек, придумавший стиральную машинку, тоже сначала долго возмущался необходимостью стирать на доске.
                                                                                                • 0
                                                                                                  Попробуйте Darcs. У него есть свои минусы, да, но зато очень дружественный консольный интерфейс.

                                                                                                  Под дружественным понимается «спрашивает вопросы». Например, набираете darcs whatsnew и darcs сам запускает less, показывая вам изменения в репозитарии относительно некоторого baseline. darcs record показывает изменения в репозитарии, спрашивает, «нужно ли вот это изменение записать?» — а вы отвечаете «да», «нет», «запиши сразу все» и т.д. Даже простой запуск darcs без аргументов выдает справку, которую можно просматривать (а не дамп в stdout, как обычно). В общем, более общительный инструмент. :)
                                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                    • 0
                                                                                                      Ну с этим-то никто не спорит (кроме того, что git, в отличие от меркуриала, вроде именно ревизии хранит, а не ченжсеты)
                                                                                                      • 0
                                                                                                        кроме того, что git, в отличие от меркуриала, вроде именно ревизии хранит, а не ченжсеты

                                                                                                        Феерический бред.
                                                                                                  • 0
                                                                                                    Вы меня извините, если я не совсем в тему, но заголовок топика следовало бы расширить до «Взгляд пользователя Eclipse». Пока не дочитал до момента с пояснением того — как вы используете VCS — сильно недоумевал.
                                                                                                    • 0
                                                                                                      Тогда уж «взгляд пользователя eclipse, mac os x, двух мониторов и деревянного стула». Что-то я программирую в eclipse, но версиями всегда рулю сторонними утилитами.
                                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                      • 0
                                                                                                        Почему на Винде нужны, а в Линуксе не нужны?
                                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                          • 0
                                                                                                            В маке тоже есть консоль, которой можно пользоваться, однако мне НУЖЕН гуишный клиент. Более того, сядь я работать за линукс, он мне точно так же был бы нужен. Его, может быть, не было бы, но он был бы мне нужен.
                                                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                              • 0
                                                                                                                Видимо, вы неправильно понимаете значение слова „нужны“. Вы его, видимо, путаете с „можно обойтись без“.
                                                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                  • 0
                                                                                                                    Еще раз, ну последний уже наверное. Если удобного инструмента нет, это не значит, что он никому не нужен.
                                                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                      • 0
                                                                                                                        > Инструмент нужно использовать по назначению, а не обсжудать «неудобство рисования векторами в фотошопе и проблемы работы с растром в иллюстраторе».

                                                                                                                        Есть люди, которые используют, что им дают, а есть те, кто думает, как сделать лучше. Очевидно, что при встрече они не понимают друг друга. Извините.
                                                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                          • +3
                                                                                                            Я против гуёв для программистов, по следующим причинам:
                                                                                                            0. Гуй может увеличить эффективность только в некоторых редких операция, в большей части случаев он не приносит пользы, а часто бывает и вреден, операции с мышью они обычно тормозные.
                                                                                                            1. На сервера ходишь по ssh — если вдруг нужно срочно что-то сделать, нужно не мануалы по командам читать и не любимы гуи ставить, а вводит давно выученные команды.
                                                                                                            3. Всякие ide и графические клиенты скрывают от программиста как это устроено, подсевшие с юности на ide часто ничего не знают про то что компилятор, отладчик и текстовый редактор это разные компоненты, и про систему сборки могут не знать. Для кодеров может это и хорошо, а для разработчиков плохо.

                                                                                                            Это касательно программистов, для остальных скажут так, если хочется фичей, то придётся немного подучиться, а кому фичей не надо, для тех есть соответствующие гуи. Я был бы только за, если бы был крутой гуй для все VCS, но потребности у меня в нём нет, и судя по комментам я не один.
                                                                                                            Надеюсь вы найдёте/напишите/поспособствуете написанию удобного гуя, и весьма вероятно, если он реально будет прост, он поможет многим непрограммистам влиться в мир пользователей VCS.
                                                                                                            • +2
                                                                                                              Всегда придерживался такой методики обучения новому языку, технологии и т. п. — сначала разбираюсь с консольными команды, ключами, структурами, форматами и т. п., а потом, разобравшись хотя бы с основами, ищу гуевины под них. Фейл был только один (вернее много, но однотипные — продукты для разработки от MS, от Borland разобрался всё же). Мне так удобнее и эффективнее получается работать (засекал по таймеру не раз, прочитав очередной пост или тред на хабре об эффективности работы в консоли с vim или emacs в качестве ide). В гуевинах, кстати, интенсивно использую хоткеи. Главный плюс гуевин для меня возможность визуально выбирать элементы в списках, деревьях и т. п., а не долбать tab и нажимать y в ответ на «Display all 3770 possibilities? (y or n)».

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