Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 52
Хобгоблин доставил неимовернейше :) Спасибо за перевод!
Мне еще это нравится (может баян): git-animals.tumblr.com/
«Я учила Unix-путь...» >< Лучше было оставить Unix-way.
А можно для тех, кто не особо крут в Гите под каждый пунктом объяснение от К.О.?
Попробую.
Начнем с того, что тут все легкий наезд на git.
Начнем с того, что тут все легкий наезд на git.
- «aliases that hide existing git commands are ignored». При этом ошибка не выводится.
- Комментарии излишни.
- В идеологии git подробное хранение истории. При этом веткам уделено настолько мало внимания, что выяснить в какой ветке внесено определенное изменение — не тривиальная задача.
Честно говоря я не уверен, что ветки удаляются не бесследно (а удаление веток после слияния предполагается идеологически). - Несогласованность параметров различных команд. Одинаковые действия с различными сущностями не имеют ни чего общего.
- И опять несогласованность. Многие консольные программы поддерживают и -h и --help и даже показывают разные варианты справки.
Но странно то, что git поддерживает -h не везде.
git branch --help и git --help branch одинаково открывают git manual
При этом git branch -h показывает короткую справку, а git -h branch — Unknown option: -h
Так вот и непонятно, отчего же гит не привели к более удобной системе команд? Ато пипец какой то.
Насколько я могу видеть, они постепенно приводят :). Тут ничего не сказали, к примеру, про «git push», который по умолчанию до версии 1.8 пушит все ветки и теги…
Мне кажется, люди любят гит больше за скорость и неприхотливость, нежели за его логичность в аргументах командной строки. Ну и сама история создания гита должна давать ответ на ваш вопрос: гит создавался как система управления патчами для kernel.org, и более-менее нормальный «пользовательский интерфейс» к нему начал появляться не так давно, и как раз он с каждой версией становится всё дружелюбнее.
Мне кажется, люди любят гит больше за скорость и неприхотливость, нежели за его логичность в аргументах командной строки. Ну и сама история создания гита должна давать ответ на ваш вопрос: гит создавался как система управления патчами для kernel.org, и более-менее нормальный «пользовательский интерфейс» к нему начал появляться не так давно, и как раз он с каждой версией становится всё дружелюбнее.
Потому что так сложилось исторически. Когда-то читал интервью про Microsoft Office, там задавали вопрос «А почему у вас так много функционала и кнопок в ворде, нельзя ли убрать всё это нагромождение, мне нужно только форматирование и печать, например, 5% от всех возможностей».
Разработчики ответили, что так и есть, каждому нужно только 5%, проблема в том, что у всех они разные. Кому-то списки и абзаца, кому-то мастер слияния писем и без него никак. И стоит только что-то убрать, всегда найдутся недовольные:
Разработчики ответили, что так и есть, каждому нужно только 5%, проблема в том, что у всех они разные. Кому-то списки и абзаца, кому-то мастер слияния писем и без него никак. И стоит только что-то убрать, всегда найдутся недовольные:
Возможности программы, согласованность интерфейса и разделение ответственности между частями программы — это три разные вещи. Никто здесь не просит убрать функционал git, здесь просят изменить интерфейс. Народ из MS, к слову, не побоялся это сделать.
Конечно, внезапный переход на новую систему — не самая хорошая идея для git. Но взять и допилить тот же libgit2 (или написать что‐то своё, но обязательно с API — его отсутствие — это один из недостатков git), сделать на его основе новый CLI с учётом всех выявленных недостатков и объявить старый вариант deprecated (с поддержкой в течение нескольких лет) они вполне могут. Альтернативу — имея чёткий план по шагам ломать старый — тоже (правда, по‐моему, первый вариант легче пережить).
Если этого не сделать то легко повторить судьбу perl — желаемых изменений накопилось на целый новый язык, но популярность старого perl продолжает падать, а новый всё ещё не готов.
Конечно, внезапный переход на новую систему — не самая хорошая идея для git. Но взять и допилить тот же libgit2 (или написать что‐то своё, но обязательно с API — его отсутствие — это один из недостатков git), сделать на его основе новый CLI с учётом всех выявленных недостатков и объявить старый вариант deprecated (с поддержкой в течение нескольких лет) они вполне могут. Альтернативу — имея чёткий план по шагам ломать старый — тоже (правда, по‐моему, первый вариант легче пережить).
Если этого не сделать то легко повторить судьбу perl — желаемых изменений накопилось на целый новый язык, но популярность старого perl продолжает падать, а новый всё ещё не готов.
Осмелюсь дополнить.
3. Коммит хранит список своих родителей, их хеши. Никаких строковых ссылок на имена веток нет. Если подмержить ветку и удалить её, то о ней не останется никакого упоминания. В истории мы просто увидим разветвление на «тут были две какие-то ветки».
В коллективной разработке я предпочитаю некоторое время удерживать ссылки на ветки даже после полного мержа. Тогда можно хотя бы достать историю по ветке (
Ещё в git нет бранчей с «разрывами».
3. Коммит хранит список своих родителей, их хеши. Никаких строковых ссылок на имена веток нет. Если подмержить ветку и удалить её, то о ней не останется никакого упоминания. В истории мы просто увидим разветвление на «тут были две какие-то ветки».
В коллективной разработке я предпочитаю некоторое время удерживать ссылки на ветки даже после полного мержа. Тогда можно хотя бы достать историю по ветке (
$ git log master..feature-branch).Ещё в git нет бранчей с «разрывами».
Потому что ветки — это не список коммитов, а указатель на головной коммит. Так что выяснить, в какой ветке внесено изменение просто невозможно после слияния. Ведь коммит будет входить во все ветки. И это правильно. Разве можно определить, какая ветвь сакуры выросла из какого корня :-)
В mercurial как раз честно: метка ветки это часть коммита.
Вообще git vs hg — это очень тонкий холивар, тоньше моего понимания.
Вообще git vs hg — это очень тонкий холивар, тоньше моего понимания.
Согласен, только вот в повседневной работе, hg (с его сокращенными командами, патчами mq) требует к себе больше внимания и времени, чем тот самый нелогичный гит.
Пользуюсь и тем, и другим, и это помимо обычных cvs-подобных систем контроля версий.
Гит не является дружелюбным, даже при использовании одним человеком, и не только потому что многие команды нелогичны. Проблема в том, что он требует слишком много моделировать в голове: вот у меня коммит, но я сейчас в ветке, и всё это еще локально, а на гитхабе еще пять коммитов новых появилось, и что в какой последовательности мне теперь делать? Садишься и чуть ли не рисуешь на бумажке первое время. При этом шанс потерять свои изменения совсем не иллюзорен, например предположу что все проходят stash + смена ветки, при этом untracked-файлы по умолчанию не включаются. И это система контроля версий, главное назначение которой хранить эти изменения!
Да, после пары месяцев, глубоких разбирательств вместо «да проще плюнуть и заново всё склонировать» и набивания всех шишек попутно с написанием самому себе памятки что-когда-в-каком-порядке можно начинать любить гит. Но не слишком ли это дорогая цена при наличии всё же более дружелюбного hg&mercurial?
Есть такой анекдот:
Русский сел на гвоздь, вскочил и давай матом ругаться. Украинец сел на гвоздь, вскочил, нащупал гвоздь, вытащил его и положил в карман: «В хозяйстве пригодится». Белорус сел на гвоздь, привстал и со словами «А может так и надо?» снова сел.
Иногда мне кажется, что давление от факта «ну все же им пользуются, может так и надо» всё-таки слишком велико.
p.s. Я понимаю, что параллельная разработка одного проекта кучей разных людей в любом случае сложная задача.
Гит не является дружелюбным, даже при использовании одним человеком, и не только потому что многие команды нелогичны. Проблема в том, что он требует слишком много моделировать в голове: вот у меня коммит, но я сейчас в ветке, и всё это еще локально, а на гитхабе еще пять коммитов новых появилось, и что в какой последовательности мне теперь делать? Садишься и чуть ли не рисуешь на бумажке первое время. При этом шанс потерять свои изменения совсем не иллюзорен, например предположу что все проходят stash + смена ветки, при этом untracked-файлы по умолчанию не включаются. И это система контроля версий, главное назначение которой хранить эти изменения!
Да, после пары месяцев, глубоких разбирательств вместо «да проще плюнуть и заново всё склонировать» и набивания всех шишек попутно с написанием самому себе памятки что-когда-в-каком-порядке можно начинать любить гит. Но не слишком ли это дорогая цена при наличии всё же более дружелюбного hg&mercurial?
Есть такой анекдот:
Русский сел на гвоздь, вскочил и давай матом ругаться. Украинец сел на гвоздь, вскочил, нащупал гвоздь, вытащил его и положил в карман: «В хозяйстве пригодится». Белорус сел на гвоздь, привстал и со словами «А может так и надо?» снова сел.
Иногда мне кажется, что давление от факта «ну все же им пользуются, может так и надо» всё-таки слишком велико.
p.s. Я понимаю, что параллельная разработка одного проекта кучей разных людей в любом случае сложная задача.
Несогласованность параметров различных команд. Одинаковые действия с различными сущностями не имеют ни чего общего.
Гм, а может имелось в виду что вместо
могли бы быть более согласующимися, чтобы было проще использовать их в пылу кодинга
деструктивные команды «специально» были сделаны так, чтобы в пылу кодинга таки нужно было включать мозг перед их выполнением?
В часть про хобгоблина еще стоило бы добавить наиочевиднейшую команту удаления remote бранча :)
git push origin :branchname
раз в неделю ее гуглю.
Начиная с Git 1.7, доступна команда
git push origin --delete branchname. Хотя, мне уже привычнее старый вариант, да и печатать меньше.И да, станет немного логичнее, если в вопросе этого двоеточия разобраться. Если писать команду полностью, то выйдет примерно так:
git push origin localbranch:remotebranch. Соответственно, если локальную ветку не указывать, оставив разделитель-двоеточие, то указанная удаленная ветка удалится.Ну я думаю это делает любой, кто задается вопросом «а с фига ли там вообще двоеточие?». Но тем не мене :)
Ок, то есть ветка с пустым именем — считается пустой веткой?
Тогда почему
не падает по причине “Non-fast forward updates were rejected” и не требует ключа --force? Ведь изменения самые что ни на есть деструктивные, и уж точно не являются fast-forward.
По этой же логике удалить локальную ветку должно быть можно командой
Тогда почему
git push origin :branchnameне падает по причине “Non-fast forward updates were rejected” и не требует ключа --force? Ведь изменения самые что ни на есть деструктивные, и уж точно не являются fast-forward.
По этой же логике удалить локальную ветку должно быть можно командой
git pull origin :localbranch
Тысячу раз благодарю TortoiseGit.
В последнее время от черепахи только отрицательные эмоции. Использую gitextensions вместо нее.
Нормальный SourceTree же вышел.
SmartGit/Hg, для некоммерческого использования бесплатно.
А я тысячу раз матерю — она жутко неудобная — столько много суетливых движений…
Только вод приходится это чудо использовать потому как почему-то консоли пугаются — юзеры, что с них взять
Только вод приходится это чудо использовать потому как почему-то консоли пугаются — юзеры, что с них взять
Интересно, кто-нибудь пользует http://hg-git.github.io/?
Для справки: плагин позволяет работать с git-репозиториями из mercurial.
Для справки: плагин позволяет работать с git-репозиториями из mercurial.
Ребят, может кому вот это понадобится: алиасы для гита
В могучем русском языке есть более однозначное слово «отдалённый», есть более однозначное (и краткое!) слово «стёртый».
Кто знает о них и продолжает употреблять «удалённый», тот виноват.
А язык винить нечего.
Кто знает о них и продолжает употреблять «удалённый», тот виноват.
А язык винить нечего.
«Отдалённый» всё же обычно употребляется к обозримым объектам. Здесь объект не обозримый для человека, особенно без переключения контекста. Да и это уже давно устоявшийся термин, причём намного более употребительный (по отношению к своим синонимам), чем он же, но в значении «стёртый». Но вот если бы вместо «удалить удалённый репозиторий» было написано «стереть удалённый репозиторий» понять смысл было бы намного легче, уж к глаголу‐то в этом значении понятных и часто употребляемых синонимов более чем достаточно.
>Мастер Гит отправил последние новейшие изменения в master
>Master Git pulled down the latest changes on master
>отправил
>pulled down
Пойду-ка я лучше читать оригинал, а то перевод с подозрением на фактические ошибки слишком выносит мозг :)
>Master Git pulled down the latest changes on master
>отправил
>pulled down
Пойду-ка я лучше читать оригинал, а то перевод с подозрением на фактические ошибки слишком выносит мозг :)
«Как мне создать ветку?»
«Используй git checkout.»
git branch %branchname%Обычно требуется не просто создать, но и сделать её текущей. В этом случае это будет этот самый
git branch $branch, затем всё равно git checkout $branch. git branch нужен в основном только если вы случайно зафиксировали изменение не в той ветке, хотите переименовать ветку, разбить её на несколько или что‐нибудь в этом роде.В повседневном использовании я тоже применяю «компактный вариант»
Однако в тексте присутствует упрёк в том что комманда checkout предназначена для выполнения различных функций:
checkout -bОднако в тексте присутствует упрёк в том что комманда checkout предназначена для выполнения различных функций:
- переход на другую ветку
- создание новой ветки
- для перехода на другую ветку предназначена команда
checkout - для создания новой ветки предназначена команда
branch - для создания новой ветки и перехода на неё возможно использовать
checkout -b
Какой вариант вы сочли бы логичным для «создания новой ветки и перехода на неё»?
git branch --сheckout %branchname%git checkoutonewbranch %branchname%- отсутствие одной команды и последовательное применение двух:
branchиcheckout
Именно поэтому
Впрочем, Kain_Haart вам достаточно ясно объяснил ситуацию.
-b это всего лишь флаг команды checkout. Странно упрекать команду за наличие удобной дополнительной опции.Впрочем, Kain_Haart вам достаточно ясно объяснил ситуацию.
Удобной дополнительная опция (а лучше поведение по‐умолчанию с одним аргументом) была бы у branch. Если бы не было git и кучи упоминаний про именно этот флаг этой команды я никогда бы не додумался искать команду для создания и переключения на новую ветку именно там.
Именно в этом и состоит, насколько я понял, претензия develop7: когда вам нужна новая ветка вы хотите создать ветку и переключиться на неё, но git предлагает только переключиться на ветку, попутно её создав. Ни до, ни после знакомства с git я не думаю об этом действии иначе, чем «создать и переключиться». А ветки создаются
Именно в этом и состоит, насколько я понял, претензия develop7: когда вам нужна новая ветка вы хотите создать ветку и переключиться на неё, но git предлагает только переключиться на ветку, попутно её создав. Ни до, ни после знакомства с git я не думаю об этом действии иначе, чем «создать и переключиться». А ветки создаются
git branch. Основное действие — «создать», не «перейти». Kain_Haart не объяснил ничего, кроме того, что мы и так знали.Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Коаны Гита