Коаны Гита

Original author: Стив Лош
  • Translation
По мотивам «Коанов Вима».

Тишина
Что-то одно, но хорошо
Только богам
Хобгоблин
Длинное и короткое

Тишина


Python-программистка передала свой файл ~/.gitconfig мастеру Гиту. Среди строчек кода было следующее:

[alias]
; Явное лучше подразумеваемового. Если мы хотим выполнить слияние,
; нам следует сделать это самим.
pull = pull --ff-only

Мастер Гит кивнул. «git pull origin master», — сказала программистка.

Мастер Гит отправил последние новейшие изменения в master и автоматически выполнил слияние с изменениями программистки.

«Но мастер Гит, разве я не просила в моей конфигурации использовать только fast-forward?» — вскричала она.

Мастер Гит посмотрел на неё, кивнул и ничего не сказал.

«Тогда почему же вы не предупредили меня о проблеме с моей конфигурацией?» — спросила она.

Мастер Гит ответил: «В ней не было проблем.»

Месяцы спустя, когда программистка по другой причине читала git --help config, она достигла просветления.

Что-то одно, но хорошо


Unix-программистка работала на кубикловой ферме. Она увидела мастера Гита, идущего по тропе, и выбежала, чтобы встретить его.

«Для меня честь встретить вас, мастер Гит», — сказала она. «Я учила путь Unix построения программ, согласно которому каждый должен делать что-то одно, но хорошо. Несомненно, я могу многому научиться у вас.»

«Несомненно», — ответил мастер Гит.

«Как я могу перейти к другой ветке?» — спросила программистка.

«Используй git checkout

«Как мне создать ветку?»

«Используй git checkout

«А как мне обновить содержимое единственного файла моей рабочей директории, вообще без использования веток?»

«Используй git checkout

После третьего ответа программистку постигло просветление.

Только богам


Великий историк пытался распутать клубок сложностей неверного слияния, которое произошло много месяцев назад. Он совершил паломничество к мастеру Гиту, чтобы просить его помощи.

«Мастер Гит, — сказал историк, — какова природа истории?»

«История непреложна. Переписывать её позже значит вредить самой материи существа.»

Историк согласился, а затем спросил: «И поэтому перебазирование коммитов, которые были внесены, не одобряется?»

«Воистину», — ответил мастер Гит.

«Великолепно!» — воскликнул историк. «У меня есть историческая запись коммита слияния с двумя другими родителями. Как я могу выяснить, из какой из веток происходит каждый из родителей?»

«История мимолётна, — ответил мастер Гит, — знание, которого ты ищешь, доступно только богам.»

Историк опустил голову, и просветление поразило его.

Хобгоблин


Ученица следовала пути мастера Гита. К концу урока она посмотрела на свои заметки и спросила: «Мастер, у меня есть несколько вопросов. Могу я задать их?»

Мастер Гит кивнул.

«Как просмотреть список всех тэгов?»

«git tag», — ответил мастер Гит.

«Как мне просмотреть список всех удаленных репозиториев?»

«git remote -v», — ответил мастер Гит.

«Как мне просмотреть список всех веток?»

«git branch -a», — ответил мастер Гит.

«А как я могу просмотреть текущую ветку?»

«git rev-parse --abbrev-ref HEAD», — ответил мастер Гит.

«Как удалить удаленный репозиторий?»

«git remote rm», — ответил мастер Гит.

«Как мне удалить ветку?»

«git branch -d», — ответил мастер Гит.

Ученица задумалась на некоторое время, затем спросила: «Конечно, некоторые из этих команд могли бы быть более согласующимися, чтобы было проще использовать их в пылу кодинга?»

Мастер Гит щелкнул пальцами. В комнате появился хобгоблин и съел ученицу заживо. В загробной жизни на неё снизошло просветление.

Длинное и короткое


Мастер Гит и ученица прогуливались по мосту.

Ученица, желая перенять безграничное знание мастера Гита, сказала: «git branch --help

Мастер Гит присел и провел лекцию о семи формах git branch и их многих опциях.

Они пошли дальше. Несколько минут спустя они встретились с опытным разработчиком, путешествующим в противоположном направлении. Он поприветствовал мастера Гита и сказал: «git branch -h.» Мастер Гит немногословно проинформировал его о самых общих опциях git branch. Разработчик поблагодарил его и продолжил свой путь.

«Мастер, — сказала ученица, — какова природа длинных и коротких команд? Я считала, они равнозначны, но когда разработчик использовал -h, вы сказали что-то отличное от того, что было сказано при --help

«Перспектива — это всё», — ответил мастер.

Ученица была озадачена. Она решила поэкспериментировать и сказала: «git -h branch

Мастер Гит развернулся и спрыгнул с перил моста, к камням, к своей смерти вниз.

При виде этого на ученицу снизошло просветление.
Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 52

    +15
    Хобгоблин доставил неимовернейше :) Спасибо за перевод!
      +1
      Присоединяюсь. Перевод отличный.
      +12
      Мне еще это нравится (может баян): git-animals.tumblr.com/
        +2
        «Я учила Unix-путь...» >< Лучше было оставить Unix-way.
          +8
          «Путь Unix»
          +15
          А можно для тех, кто не особо крут в Гите под каждый пунктом объяснение от К.О.?
            +43
            Попробую.

            Начнем с того, что тут все легкий наезд на git.

            1. «aliases that hide existing git commands are ignored». При этом ошибка не выводится.
            2. Комментарии излишни.
            3. В идеологии git подробное хранение истории. При этом веткам уделено настолько мало внимания, что выяснить в какой ветке внесено определенное изменение — не тривиальная задача.
              Честно говоря я не уверен, что ветки удаляются не бесследно (а удаление веток после слияния предполагается идеологически).
            4. Несогласованность параметров различных команд. Одинаковые действия с различными сущностями не имеют ни чего общего.
            5. И опять несогласованность. Многие консольные программы поддерживают и -h и --help и даже показывают разные варианты справки.
              Но странно то, что git поддерживает -h не везде.
              git branch --help и git --help branch одинаково открывают git manual
              При этом git branch -h показывает короткую справку, а git -h branch — Unknown option: -h
              +8
              Так вот и непонятно, отчего же гит не привели к более удобной системе команд? Ато пипец какой то.
                +3
                Насколько я могу видеть, они постепенно приводят :). Тут ничего не сказали, к примеру, про «git push», который по умолчанию до версии 1.8 пушит все ветки и теги…

                Мне кажется, люди любят гит больше за скорость и неприхотливость, нежели за его логичность в аргументах командной строки. Ну и сама история создания гита должна давать ответ на ваш вопрос: гит создавался как система управления патчами для kernel.org, и более-менее нормальный «пользовательский интерфейс» к нему начал появляться не так давно, и как раз он с каждой версией становится всё дружелюбнее.
                  +4
                  Потому что так сложилось исторически. Когда-то читал интервью про Microsoft Office, там задавали вопрос «А почему у вас так много функционала и кнопок в ворде, нельзя ли убрать всё это нагромождение, мне нужно только форматирование и печать, например, 5% от всех возможностей».

                  Разработчики ответили, что так и есть, каждому нужно только 5%, проблема в том, что у всех они разные. Кому-то списки и абзаца, кому-то мастер слияния писем и без него никак. И стоит только что-то убрать, всегда найдутся недовольные:

                  image
                    +2
                    Возможности программы, согласованность интерфейса и разделение ответственности между частями программы — это три разные вещи. Никто здесь не просит убрать функционал git, здесь просят изменить интерфейс. Народ из MS, к слову, не побоялся это сделать.

                    Конечно, внезапный переход на новую систему — не самая хорошая идея для git. Но взять и допилить тот же libgit2 (или написать что‐то своё, но обязательно с API — его отсутствие — это один из недостатков git), сделать на его основе новый CLI с учётом всех выявленных недостатков и объявить старый вариант deprecated (с поддержкой в течение нескольких лет) они вполне могут. Альтернативу — имея чёткий план по шагам ломать старый — тоже (правда, по‐моему, первый вариант легче пережить).

                    Если этого не сделать то легко повторить судьбу perl — желаемых изменений накопилось на целый новый язык, но популярность старого perl продолжает падать, а новый всё ещё не готов.
                  +3
                  Осмелюсь дополнить.
                  3. Коммит хранит список своих родителей, их хеши. Никаких строковых ссылок на имена веток нет. Если подмержить ветку и удалить её, то о ней не останется никакого упоминания. В истории мы просто увидим разветвление на «тут были две какие-то ветки».
                  В коллективной разработке я предпочитаю некоторое время удерживать ссылки на ветки даже после полного мержа. Тогда можно хотя бы достать историю по ветке ($ git log master..feature-branch).
                  Ещё в git нет бранчей с «разрывами».
                    +1
                    Ошибся. После слияния $ git log master..feature-branch работать не будет.
                    Пользуюсь $ git log --graph.
                    +2
                    Потому что ветки — это не список коммитов, а указатель на головной коммит. Так что выяснить, в какой ветке внесено изменение просто невозможно после слияния. Ведь коммит будет входить во все ветки. И это правильно. Разве можно определить, какая ветвь сакуры выросла из какого корня :-)
                      +5
                      в mercurial можно. правда, нечестно?
                        +2
                        В mercurial как раз честно: метка ветки это часть коммита.
                        Вообще git vs hg — это очень тонкий холивар, тоньше моего понимания.
                          +1
                          Согласен, только вот в повседневной работе, hg (с его сокращенными командами, патчами mq) требует к себе больше внимания и времени, чем тот самый нелогичный гит.
                            +7
                            Пользуюсь и тем, и другим, и это помимо обычных cvs-подобных систем контроля версий.

                            Гит не является дружелюбным, даже при использовании одним человеком, и не только потому что многие команды нелогичны. Проблема в том, что он требует слишком много моделировать в голове: вот у меня коммит, но я сейчас в ветке, и всё это еще локально, а на гитхабе еще пять коммитов новых появилось, и что в какой последовательности мне теперь делать? Садишься и чуть ли не рисуешь на бумажке первое время. При этом шанс потерять свои изменения совсем не иллюзорен, например предположу что все проходят stash + смена ветки, при этом untracked-файлы по умолчанию не включаются. И это система контроля версий, главное назначение которой хранить эти изменения!

                            Да, после пары месяцев, глубоких разбирательств вместо «да проще плюнуть и заново всё склонировать» и набивания всех шишек попутно с написанием самому себе памятки что-когда-в-каком-порядке можно начинать любить гит. Но не слишком ли это дорогая цена при наличии всё же более дружелюбного hg&mercurial?

                            Есть такой анекдот:
                            Русский сел на гвоздь, вскочил и давай матом ругаться. Украинец сел на гвоздь, вскочил, нащупал гвоздь, вытащил его и положил в карман: «В хозяйстве пригодится». Белорус сел на гвоздь, привстал и со словами «А может так и надо?» снова сел.

                            Иногда мне кажется, что давление от факта «ну все же им пользуются, может так и надо» всё-таки слишком велико.

                            p.s. Я понимаю, что параллельная разработка одного проекта кучей разных людей в любом случае сложная задача.
                              0
                              Я выразил субъективное мнение, которое может отличаться от вашего. Для меня гит проще в использовании и экономит время, нежели «мода» на этот продукт. Плюсы покажут кому что больше по душе)))
                      +1
                      Несогласованность параметров различных команд. Одинаковые действия с различными сущностями не имеют ни чего общего.

                      Гм, а может имелось в виду что вместо
                      могли бы быть более согласующимися, чтобы было проще использовать их в пылу кодинга

                      деструктивные команды «специально» были сделаны так, чтобы в пылу кодинга таки нужно было включать мозг перед их выполнением?
                        +2
                        Список всех — деструктивная команда?

                        Запутывание чего угодно — плохая идея.
                          +2
                          деструктивные команды «специально» были сделаны так
                          Бритва Хэнлона
                      +15
                      В часть про хобгоблина еще стоило бы добавить наиочевиднейшую команту удаления remote бранча :)

                      git push origin :branchname
                        +8
                        раз в неделю ее гуглю.
                          +5
                          Начиная с Git 1.7, доступна команда git push origin --delete branchname. Хотя, мне уже привычнее старый вариант, да и печатать меньше.
                            +3
                            И да, станет немного логичнее, если в вопросе этого двоеточия разобраться. Если писать команду полностью, то выйдет примерно так: git push origin localbranch:remotebranch. Соответственно, если локальную ветку не указывать, оставив разделитель-двоеточие, то указанная удаленная ветка удалится.
                              +3
                              Ну я думаю это делает любой, кто задается вопросом «а с фига ли там вообще двоеточие?». Но тем не мене :)
                                +5
                                Ок, то есть ветка с пустым именем — считается пустой веткой?

                                Тогда почему
                                git push origin :branchname
                                не падает по причине “Non-fast forward updates were rejected” и не требует ключа --force? Ведь изменения самые что ни на есть деструктивные, и уж точно не являются fast-forward.

                                По этой же логике удалить локальную ветку должно быть можно командой
                                git pull origin :localbranch
                                  +2
                                  Это Же Совсем Другое Дело
                              +2
                              Тысячу раз благодарю TortoiseGit.
                                +3
                                В последнее время от черепахи только отрицательные эмоции. Использую gitextensions вместо нее.
                                  +2
                                  Нормальный SourceTree же вышел.
                                    +1
                                    SmartGit/Hg, для некоммерческого использования бесплатно.
                                    +1
                                    А я тысячу раз матерю — она жутко неудобная — столько много суетливых движений…
                                    Только вод приходится это чудо использовать потому как почему-то консоли пугаются — юзеры, что с них взять
                                    +1
                                    Интересно, кто-нибудь пользует http://hg-git.github.io/?
                                    Для справки: плагин позволяет работать с git-репозиториями из mercurial.
                                      +1
                                      А кстати, где-бы почитать умную статью-сравнение git и mercurial?
                                        +2
                                        kernel.org оно не осиливает, а в остальном нормально
                                        +2
                                        Ребят, может кому вот это понадобится: алиасы для гита
                                          +3
                                          Целых десять секунд перечитывал и постигал «Как удалить удаленный репозиторий?»… Удалить удалённое… Удалить то, что уже удалено… О, могучий русский!!! Снизошло прозрение! :)
                                            +4
                                            В могучем русском языке есть более однозначное слово «отдалённый», есть более однозначное (и краткое!) слово «стёртый».

                                            Кто знает о них и продолжает употреблять «удалённый», тот виноват.

                                            А язык винить нечего.
                                              +2
                                              «Отдалённый» всё же обычно употребляется к обозримым объектам. Здесь объект не обозримый для человека, особенно без переключения контекста. Да и это уже давно устоявшийся термин, причём намного более употребительный (по отношению к своим синонимам), чем он же, но в значении «стёртый». Но вот если бы вместо «удалить удалённый репозиторий» было написано «стереть удалённый репозиторий» понять смысл было бы намного легче, уж к глаголу‐то в этом значении понятных и часто употребляемых синонимов более чем достаточно.
                                            +1
                                            >Мастер Гит отправил последние новейшие изменения в master
                                            >Master Git pulled down the latest changes on master

                                            >отправил
                                            >pulled down

                                            Пойду-ка я лучше читать оригинал, а то перевод с подозрением на фактические ошибки слишком выносит мозг :)
                                              –2
                                              «Как мне создать ветку?»
                                              «Используй git checkout.»
                                              git branch %branchname%
                                                +2
                                                Обычно требуется не просто создать, но и сделать её текущей. В этом случае это будет этот самый git branch $branch, затем всё равно git checkout $branch. git branch нужен в основном только если вы случайно зафиксировали изменение не в той ветке, хотите переименовать ветку, разбить её на несколько или что‐нибудь в этом роде.
                                                  +1
                                                  В повседневном использовании я тоже применяю «компактный вариант» checkout -b

                                                  Однако в тексте присутствует упрёк в том что комманда checkout предназначена для выполнения различных функций:
                                                  1. переход на другую ветку
                                                  2. создание новой ветки
                                                  В то время как:
                                                  1. для перехода на другую ветку предназначена команда checkout
                                                  2. для создания новой ветки предназначена команда branch
                                                  3. для создания новой ветки и перехода на неё возможно использовать checkout -b
                                                    +2
                                                    Именно. Ветка создаётся командой переключения в другую ветку. Это как если бы команда cd -b foo создавала каталог foo.
                                                      +1
                                                      Какой вариант вы сочли бы логичным для «создания новой ветки и перехода на неё»?
                                                      1. git branch --сheckout %branchname%
                                                      2. git checkoutonewbranch %branchname%
                                                      3. отсутствие одной команды и последовательное применение двух: branch и checkout
                                                        +1
                                                        Первый. Хотя менее interrupting workflow всё равно не становится.
                                                        +1
                                                        Именно поэтому -b это всего лишь флаг команды checkout. Странно упрекать команду за наличие удобной дополнительной опции.
                                                        Впрочем, Kain_Haart вам достаточно ясно объяснил ситуацию.
                                                          +2
                                                          претензии к вывернутой наизнанку логике формата «хвост машет собакой».
                                                            +1
                                                            А почему не пэссив? Хвост машется собакой?
                                                            +3
                                                            Удобной дополнительная опция (а лучше поведение по‐умолчанию с одним аргументом) была бы у branch. Если бы не было git и кучи упоминаний про именно этот флаг этой команды я никогда бы не додумался искать команду для создания и переключения на новую ветку именно там.

                                                            Именно в этом и состоит, насколько я понял, претензия develop7: когда вам нужна новая ветка вы хотите создать ветку и переключиться на неё, но git предлагает только переключиться на ветку, попутно её создав. Ни до, ни после знакомства с git я не думаю об этом действии иначе, чем «создать и переключиться». А ветки создаются git branch. Основное действие — «создать», не «перейти». Kain_Haart не объяснил ничего, кроме того, что мы и так знали.

                                                  Only users with full accounts can post comments. Log in, please.