немного о git'е

[avva]

(эта запись может быть интересна программистам)

Наверное, это неправильно, что меня так смешит запись Reset Demystified. Если вкратце, то автор книги Pro Git (!), признается в том, что мало написал о команде git reset в своей книге, потому что плохо ее понимал (!!). Но с тех пор он прочитал о ней побольше, и сейчас объяснит ее раз и навсегда, в блог-записи на 17 страниц!

Можно ли придумать более убедительную демонстрацию извращенности и враждебности командной строки гита? У команды git reset, которая потенциально может полностью стереть ваши изменения навсегда, есть три разных подвида, каждый из которых делает совершенно разную работу, и еще один из этих подвидов очень похож на другую команду, git checkout, но только в одном из ее подвидов - другой опять-таки делает совершенно другое! Но ничего, все станет кристально ясно, как только мы изучим полезнейшую сводную таблицу в конце записи:



Правда, теперь все понятно?

Я вспомнил, когда это прочитал, как два или три года назад мне так же было смешно, когда в Hacker News обсуждали новый сайт "Daily git tips". Я пытался сказать одну простую вещь: если вам для работы с системой управления версиями нужен сайт с ежедневными новыми советами, то что-то не так в вашей системе. Но меня, кажется, не очень поняли. Или не согласились.

Comments

[sanmai]

Никто же не заставляет вас пользоваться всеми вариантами команды reset?

Сайтов с ежедневными новыми советами по любой теме навалом, какую не возьми. Потому это явление никак не может считаться аргументом против чего-либо.

[vzaliva.livejournal.com]

одна из причин почему я предпочитаю mercurial

[juri-jurta.livejournal.com]

В Bazaar больше возможностей (например, поддержка bound branches).

[zhengxi.livejournal.com]

+1 за меркуриал, тем более что им можно работать с гит-сервером.

гит вообще контринтуитивен и хрупок, начиная от наличия там индекса (с содержанием отличным от всего вокруг), ибаторики с сертификатами (внезапных отказов работать из-за wrong CA) до вот таких-вот reset.

[neatfires.livejournal.com]

перешел на меркуриал с гита, и раз в пару недель нет-нет, да и прокляну. спору нет, манюал у гита не ахти, и команды местами запутаны. но как-то так получается, что все равно на практике цены ему нет

[msh.livejournal.com]

Ну да, а для тех, кому git недостаточно запутан, Google еще придумал repo :-)

[avva.livejournal.com]

А, я даже и не знал об этом (ничего не писал под Андроид пока что).

[helvegr.livejournal.com]

> признается в том, что мало написал о команде git reset в своей
> книге, потому что плохо ее понимал

Ну, собственно, это говорит о том, что git можно успешно
пользоваться и не разбираясь в этих тонкостях.

[develop7]

и каждый пользователь, который не разбирается в этих тонкостях, пишет о git книгу, название которой начинается с «Pro»(fessional)?

[amosk.livejournal.com]

Если вам для освоения профессии нужно много лет учиться, то что-то не так в вашей профессии :)

Вообще когда кто-то упомнает git в контексте сложности изучения - это к срачу. Вот там уже выше в комментах написали что а вот в меркуриале дескать все зашибись.

А конкретно по технической стороне темы: новичку достаточно знать reset --hard [commit] для того чтобы откатывать ветку (ну и конечно всегда коммитить перед reset - тогда по логу коммитов всегда можно восстановить все что было откачено).

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

[develop7]

Слишком много усилий для освоения второстепенного инструмента, в затылок которому дышит толпа аналогов. А под Mercurial есть hg-git, который позволяет вообще не менять хостинг репозиториев.

[bvlb.livejournal.com]

у меня последнее время точно такое же ощущение, но не от git'а, а от английской грамматики.

[stas]

Непонятного мало, но я бы тоже не согласился. Гит просто имеет функций на пару порядков больше, чем его предшественники. Да, 90% этих функций 90% времени не нужны. Но уж когда нужны, так уж нужны. Разумеется, некоторые real men презираются системы, где много опций, и никогда не пользуются vim (emacs они вообще считают воплощением лично Диавола), а только sed, потому что у vim слишком много опций. Я, например, не принадлежу к таким людям - я считаю, что принцип make simple things easy and complex things possible вполне осмыслен и гит ему следует. Да, в нём больше complex things - потому что это complex things с чем-то типа svn были вообще либо незовможны, либо делались с помощью лома и такой-то матери.

Что касается "команды git reset, которая потенциально может полностью стереть ваши изменения навсегда" - duh, эта команда для того и предназначена, чтобы стирать изменения! Она и называется reset, а не please-save-my-changes, именно поэтому. Это как жаловаться, что ножом можно порезаться. На то он и нож! А опций у неё много, потому как изменения бывают разные - которые только внесли в файлы? Которые собрались коммитить? Которые уже закоммитили? Разным изменениям - разные опции. Не нужно - не пользуйтесь, запомните один reset --hard и в 90% достаточно. Можно даже алиас прописать, если руки устают набирать.

[kaathewise.livejournal.com]

Подписываюсь под каждым словом. Еще бы хотел добавить, что у команды git reset три подвида делают не "совершенно разную работу", как пишет avva, ведь следующая команда включает в себя предыдущую, и все что они все делают - это 3 ступени отката коммита.

[yan.livejournal.com]

Daily git tips: а что же, там в самом деле все советы всегда новые? У меня вот стоит на машине fortune, так и она повторяется.

[avva.livejournal.com]

Это по замыслу типа блог был.

[zelych.livejournal.com]

Отличная статья.
git'ом больше года пользуюсь и никогда не читал никаких толстых мануалов про него. И, помнится, только после этой статьи наконец понял про The Three Trees of Git и перестал каждый раз гуглить "git revert last commit".

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

[develop7]

самое забавное, что эти же люди будут продолжать настаивать, что «git простой и понятный».

[plakhov.livejournal.com]

Угу, и не поймут. Это люди, лишенные чувства собственной смертности, я им иногда завидую.

[emdin.livejournal.com]

Гитом я научился пользоваться примерно за два дня. Clearcase я изучал на двухнедельных курсах, что не мешало раз в несколько месяцев сталкиваться с проблемами и ошибками, которые можно было разрешить только с помощью специально обученных людей из build coordination center. В корпоративном руководстве по СС было несколько команд, про которые просто было написано -- "не использовать, опасно". Правда, теперь всё понятно?

[vasaku.livejournal.com]

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

[janatem.livejournal.com]

Вопрос в том, чтобы отобразить набор понятий гита в команды и сделать это интуитивно понятно? Если так, то я соглашусь, что здесь есть над чем работать. (Вместо git reset --hard говорить git hard-reset?) Но это не очень важно, можно привыкнуть и к этой странной конвенции или даже налепить своих алиасов на основные операции.

Но, пытаясь ответить на вопрос «почему гит вообще такой сложный?», скажу, что ответ на него лежит в области математики. В основе лежит несколько базовых понятий, над которыми довольно естественным образом (т.е. как бы сама!) строится вся система. В качестве аналогии можно упомянуть машину Тьюринга — базовые понятия просты, но потом как бы случайно оказывается, что любой алгоритм, который можно помыслить, выражается в виде программы для этой машины. И образуется целая научная дисциплина с кучей открытых проблем.

Действительно, как было отмечено выше, бо́льшая часть функциональности гита — не для каждодневного использования. Чтобы снять тот же слой функциональности, что предоставляет, например, subversion, достаточно изучить примерно такой же объем мануалов. И только если захочется странного, придется потрудиться. Мне как-то понадобилось разобраться, как превращать поддиректории в ветки и наоборот (в subversion такая проблема вообще не стоит, поскольку там нет понятия ветки; ветка (и тег) — это всего лишь конвенциональная поддиректория). Я реально убил день, вкуривая мануалы, но в конце-концов научился это делать. Причем реальность (да, я использую именно слово «реальность», а не «особенности реализации», «идеология системы» и т.д.) такова, что инструменты, необходимые для этого, вроде бы простого, действия, настолько мощны, что позволяют произвести любое мыслимое преобразование над деревом объектов, и, как следствие, довольно сложны. Если бы идеология диктовала иметь отдельный инструмент для каждого из подобных действий, то пришлось бы заводить их тысячами. Такая политика годится лишь для VCS с сильно редуцированной функциональностью, благо их уже существует множество на любой вкус.

[develop7]

Я не пойму вот чего. Почему для того, чтобы эффективно и осознанно пользоваться VCS с якобы «редуцированной функциональностью», изучать их внутреннее устройство абсолютно не обязательно?

[kingoleg.livejournal.com]

Не зачет

[janatem.livejournal.com]

Пинок git'у с другой стороны — хочу, чтоб добавили команду git copy.

[dimas.livejournal.com]

ну да, гит это инструмент, которым можно выстрелить себе в ногу или даже задницу, десятью разными способами :)

но за один только git stash можно простить многое :) я даже с рабочим svn-ом из гита работаю, ибо удобнее и быстрее ...

да и тот же git stash полезно делать перед использованием неизвестной команды :)

[nec-p1us-u1tra.livejournal.com]

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

[http://users.livejournal.com/sorcerer_/]

+1000
Пришлось гнать mercurial ссаными тряпками из проекта за это.

[not-resident.livejournal.com]

Git is architecturally divided into two major parts: the plumbing and the turds. (@bos31337 (https://twitter.com/#!/bos31337/status/164136020625989634))

[konstantin tenzin (from livejournal.com)]

Забавно. Так долго разжевывать тривиальную вещь :) Если честно, автор меня удивил.

Не очень понимаю, кстати, замечаний о сложности гита. После некоторого обучения используется легко. Мы недавно перевели нашу компанию на использование git (c clearcase, starteam, subversion, cvs). Переход прошел гладко и впечатления хорошие. При всем этом гит позволяет быть очень эффективным, если узнать чуть больше, чем нужно для повседневной работы.

Сам я, в свое время эволюционировал в направлении vss => subversion => mercurial => git => ????

[max630.livejournal.com]

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

[volk007.livejournal.com]

ну с git5 лучше чем без git5, а вообще у меня давно выработался надежный способ работы с git: google what you want to do, cut-n-paste from the first answer at stackoverflow :)

[develop7]

таким образом, man git* можно смело выкидывать нафиг — 90% этого всё равно не заметит.