Коаны Гита

[ImperfectCadenca]

Хобгоблин доставил неимовернейше :) Спасибо за перевод!

[dector]

Присоединяюсь. Перевод отличный.

[dea]

Мне еще это нравится (может баян): git-animals.tumblr.com/

[Longer]

«Я учила Unix-путь...» >< Лучше было оставить Unix-way.

[Zelgadis]

«Путь Unix»

[TheShock]

А можно для тех, кто не особо крут в Гите под каждый пунктом объяснение от К.О.?

[senia]

Попробую.

Начнем с того, что тут все легкий наезд на 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
   

[AmirL]

Так вот и непонятно, отчего же гит не привели к более удобной системе команд? Ато пипец какой то.

[youROCK]

Насколько я могу видеть, они постепенно приводят :). Тут ничего не сказали, к примеру, про «git push», который по умолчанию до версии 1.8 пушит все ветки и теги…

Мне кажется, люди любят гит больше за скорость и неприхотливость, нежели за его логичность в аргументах командной строки. Ну и сама история создания гита должна давать ответ на ваш вопрос: гит создавался как система управления патчами для kernel.org, и более-менее нормальный «пользовательский интерфейс» к нему начал появляться не так давно, и как раз он с каждой версией становится всё дружелюбнее.

[sphinxy]

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

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

[ZyXI]

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

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

Если этого не сделать то легко повторить судьбу perl — желаемых изменений накопилось на целый новый язык, но популярность старого perl продолжает падать, а новый всё ещё не готов.

[StreetStrider]

Осмелюсь дополнить.
3. Коммит хранит список своих родителей, их хеши. Никаких строковых ссылок на имена веток нет. Если подмержить ветку и удалить её, то о ней не останется никакого упоминания. В истории мы просто увидим разветвление на «тут были две какие-то ветки».
В коллективной разработке я предпочитаю некоторое время удерживать ссылки на ветки даже после полного мержа. Тогда можно хотя бы достать историю по ветке ($ git log master..feature-branch).
Ещё в git нет бранчей с «разрывами».

[StreetStrider]

Ошибся. После слияния $ git log master..feature-branch работать не будет.
Пользуюсь $ git log --graph.

[ctacka]

Потому что ветки — это не список коммитов, а указатель на головной коммит. Так что выяснить, в какой ветке внесено изменение просто невозможно после слияния. Ведь коммит будет входить во все ветки. И это правильно. Разве можно определить, какая ветвь сакуры выросла из какого корня :-)

[ctacka]

В mercurial как раз честно: метка ветки это часть коммита.
Вообще git vs hg — это очень тонкий холивар, тоньше моего понимания.

[drdim]

Согласен, только вот в повседневной работе, hg (с его сокращенными командами, патчами mq) требует к себе больше внимания и времени, чем тот самый нелогичный гит.

[sphinxy]

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

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

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

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

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

p.s. Я понимаю, что параллельная разработка одного проекта кучей разных людей в любом случае сложная задача.

[drdim]

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

[timurrrr]

Несогласованность параметров различных команд. Одинаковые действия с различными сущностями не имеют ни чего общего.

Гм, а может имелось в виду что вместо

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

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

[senia]

Список всех — деструктивная команда?

Запутывание чего угодно — плохая идея.

[Halt]

В часть про хобгоблина еще стоило бы добавить наиочевиднейшую команту удаления remote бранча :)

git push origin :branchname

[spacediver]

раз в неделю ее гуглю.

[Neris]

Начиная с Git 1.7, доступна команда git push origin --delete branchname. Хотя, мне уже привычнее старый вариант, да и печатать меньше.

[Neris]

И да, станет немного логичнее, если в вопросе этого двоеточия разобраться. Если писать команду полностью, то выйдет примерно так: git push origin localbranch:remotebranch. Соответственно, если локальную ветку не указывать, оставив разделитель-двоеточие, то указанная удаленная ветка удалится.

[Halt]

Ну я думаю это делает любой, кто задается вопросом «а с фига ли там вообще двоеточие?». Но тем не мене :)

[burdakovd]

Ок, то есть ветка с пустым именем — считается пустой веткой?

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

По этой же логике удалить локальную ветку должно быть можно командой
git pull origin :localbranch

[Mithgol]

Тысячу раз благодарю TortoiseGit.

[Neris]

В последнее время от черепахи только отрицательные эмоции. Использую gitextensions вместо нее.

[homm]

Нормальный SourceTree же вышел.

[Beholder]

SmartGit/Hg, для некоммерческого использования бесплатно.

[iborzenkov]

А я тысячу раз матерю — она жутко неудобная — столько много суетливых движений…
Только вод приходится это чудо использовать потому как почему-то консоли пугаются — юзеры, что с них взять

[anjensan]

Интересно, кто-нибудь пользует http://hg-git.github.io/?
Для справки: плагин позволяет работать с git-репозиториями из mercurial.

[tangro]

А кстати, где-бы почитать умную статью-сравнение git и mercurial?

[kicum]

Ребят, может кому вот это понадобится: алиасы для гита

[Mithgol]

В могучем русском языке есть более однозначное слово «отдалённый», есть более однозначное (и краткое!) слово «стёртый».

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

А язык винить нечего.

[ZyXI]

«Отдалённый» всё же обычно употребляется к обозримым объектам. Здесь объект не обозримый для человека, особенно без переключения контекста. Да и это уже давно устоявшийся термин, причём намного более употребительный (по отношению к своим синонимам), чем он же, но в значении «стёртый». Но вот если бы вместо «удалить удалённый репозиторий» было написано «стереть удалённый репозиторий» понять смысл было бы намного легче, уж к глаголу‐то в этом значении понятных и часто употребляемых синонимов более чем достаточно.

[Gaen]

>Мастер Гит отправил последние новейшие изменения в master
>Master Git pulled down the latest changes on master

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

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

[Kain_Haart]

«Как мне создать ветку?»
«Используй git checkout.»

git branch %branchname%

[ZyXI]

Обычно требуется не просто создать, но и сделать её текущей. В этом случае это будет этот самый git branch $branch, затем всё равно git checkout $branch. git branch нужен в основном только если вы случайно зафиксировали изменение не в той ветке, хотите переименовать ветку, разбить её на несколько или что‐нибудь в этом роде.

[Kain_Haart]

В повседневном использовании я тоже применяю «компактный вариант» checkout -b

Однако в тексте присутствует упрёк в том что комманда checkout предназначена для выполнения различных функций:

1. переход на другую ветку
2. создание новой ветки

В то время как:

1. для перехода на другую ветку предназначена команда checkout
2. для создания новой ветки предназначена команда branch
3. для создания новой ветки и перехода на неё возможно использовать checkout -b

[Kain_Haart]

Какой вариант вы сочли бы логичным для «создания новой ветки и перехода на неё»?

1. git branch --сheckout %branchname%
2. git checkoutonewbranch %branchname%
3. отсутствие одной команды и последовательное применение двух: branch и checkout

[StreetStrider]

Именно поэтому -b это всего лишь флаг команды checkout. Странно упрекать команду за наличие удобной дополнительной опции.
Впрочем, Kain_Haart вам достаточно ясно объяснил ситуацию.

[TheShock]

А почему не пэссив? Хвост машется собакой?

[ZyXI]

Удобной дополнительная опция (а лучше поведение по‐умолчанию с одним аргументом) была бы у branch. Если бы не было git и кучи упоминаний про именно этот флаг этой команды я никогда бы не додумался искать команду для создания и переключения на новую ветку именно там.

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