27 января 2011 в 16:09

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

Предупреждение: Эта статья вас ничему не научит. Это очень высокоуровневый взгляд, мои мысли, моя рефлексия на вопрос, который для меня важен + небольшое этнографическое исследование по графическим клиентам 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, можно и нужно делать удобный, простой и понятный интерфейс, с новыми метафорами, действиями, возможностями; интерфейс, убирающий недостатки, а не повторяющий их; но все как один раз за разом повторяют то, что от бессилия наклепали авторы консольного интерфейса. Я настаиваю, что сегодняшние РСУВ — это не готовые к использованию продукты, а платформы, которые пока еще только ждут своего продукта.

Никита Прокопов @tonsky
карма
139,2
рейтинг 0,0
Похожие публикации
Самое читаемое Разработка

Комментарии (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
        ого. ну тогда ок.
      • 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
      :))))
  • +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)».

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