За вдохновение спасибо коанам Vim.
Программист на Python вручила свой ~/.gitconfig Мастеру Git. Среди многих других там были такие строки:
[alias]
; Явное лучше неявного. Если мы хотим объединить изменения, следует делать это самостоятельно.
pull = pull --ff-onlyМастер Git кивнул. "git pull origin master", сказала программист.
Мастер Git вытянул последние изменения из master и автоматически объединил их с изменениями программиста.
«Но Мастер Git, разве я не разрешала в конфигурации только fast-forward?!» вскричала она.
Мастер Git посмотрел на неё, кивнул и ничего не сказал.
«Но почему тогда ты не предупредил меня о проблеме с конфигурацией?», спросила она.
Мастер Git ответил: «не было там никакой проблемы».
Месяцы спустя, во время чтения git --help config по другому поводу, программист обрела просветление.
Программист под UNIX работала на ферме в своей кабинке. Увидев Мастера Git, бредущего по дороге, она побежала ему навстречу.
«Такая честь встретить вас, Мастер Git!» сказала она. «Я изучала путь UNIX в дизайне программ, каждая из которых делает хорошо что-то одно. Наверняка я смогу много чему научиться у вас.»
«Наверняка,» ответил Мастер Git.
«Как переключиться на другую ветку?» спросила программист.
«Используй git checkout.»
«А как мне создать ветку?»
«Используй git checkout.»
«А как обновить содержимое файла в рабочем каталоге, не вмешивая ветки?»
«Используй git checkout.»
После этого третьего ответа программист обрела просветление.
Великий историк пытался распутать хитросплетения некорректного слияния, произошедшего много месяцев тому. Он совершил паломничество к Мастеру Git, чтобы просить его помощи.
«Мастер Git,» сказал историк, «какова природа истории?»
«История неизменна. Переписывание её есть искажение самой ткани сущего.»
Историк кивнул и спросил: «Именно поэтому rebase выпнутых коммитов не поощряется?»
«Несомненно,» сказал Мастер Git.
«Великолепно!» воскликнул историк. «У меня есть исторические документы о merge-коммите с двумя родителями. Как узнать, к какой из веток принадлежал каждый родитель?»
«История эфемерна,» ответил Мастер Git, «жажду сего знания лишь боги могут утолить.»
Лишь только историк повесил голову, как просветление сокрушило его.
В обучении у Мастера Git был послушник. В конце урока он просмотрел свои заметки и сказал «Мастер, у меня есть пару вопросов. Разрешите их задать?»
Мастер Git кивнул.
«Как получить список всех тэгов?»
«git tag», ответил Мастер Git.
«Как получить список всех remoteов?»
«git remote -v», ответил Мастер Git.
«Как увидеть список всех веток?»
«git branch -a», ответил Мастер Git.
«А как увидеть текущую ветку?»
«git rev-parse --abbrev-ref HEAD», ответил Мастер Git.
«Как мне удалить remote?»
«git remote rm», ответил Мастер Git.
«А как удалить ветку?»
«git branch -d», ответил Мастер Git.
Послушник подумал немного и спросил: «Несомненно, некоторые из них могли быть и более согласованными, чтобы их было легче запомнить в разгаре кодинга, не так ли?»
Мастер Git щёлкнул пальцами. В комнату вошёл леший и сожрал послушника заживо. В загробной жизни послушник обрёл просветление.
Мастер Git и послушница шли по мосту.
Послушница, желая причаститься обширных знаний Мастера Git, сказала: «git branch --help».
Мастер Git сел и прочитал ей поучение о семи формах git branch и множестве их опций.
Они продолжили путь. Пару минут спустя они встретили опытного разработчика, шедшего в обратном направлении. Тот поклонился Мастеру Git и сказал «git branch -h». Мастер Git кратко оповестил его о самых распространённых опциях git branch. Разработчик поблагодарил его и продолжил свой путь.
«Мастер,» сказала послушница, «какова природа длинных и коротких опций команд? Я думала, что они эквивалентны, но когда разработчик использовал -h, Вы сказали не то же, чем когда я сказала --help.»
«Перспектива есть всё,» ответил Мастер.
Послушница была озадачена. Она решила поэкспериментировать и сказала «git -h branch».
Мастер Git повернулся и бросился через перила, навстречу смерти от скал внизу.
Увидев это, послушница обрела просветление.