Что: 3605f863a029ba28f8258bc023f94ef1045b20dc
Когда: 2020-11-07 12:08:18+03:00
Темы: git tip
Команды git-а: worktree, subtree https://blog.meain.io/2020/bunch-of-git-stuff/ Показаны примеры применения относительно новых команд worktree/subtree. Первую я на практике использовал несколько раз -- есть случаи когда реально полезно и удобно с ней. Но запросто у человека может и не возникнуть надобности в ней. subtree не использовал, и вот с ходу пока даже не могу представить когда бы понадобилась лично мне (так то в статье есть примеры). Вообще если бы я не знал git, то судя по статьям/рассылкам/блогам вряд ли бы к нему подступался, ибо только ленивый не говорит что он дико сложный и не понятный. Это также подтверждалось постоянно и на работах, где люди с трудом въезжают в него. Да и если объективно прикинуть, то достаточно посмотреть на git reset: что делает эта команда? Чего только не делает! git checkout? Аналогично! Ну или я (до сих пор), как минимум, не в состоянии коротко и ясно сказать для чего они. Они много для чего и это увеличивает порог входа. В ivi из-за плохих пониманий git-а (точнее применимости и допустимости некоторых практик) некоторым командам запрещалось делать git cherry-pick или rebase-ы, особенно интерактивные. git -- мощный инструмент, но который в "плохих" руках может и вредить. Защиты от дурака в нём не много. У меня никогда не возникало проблем с git-ом. Во-первых, мне никто никогда с ним не помогал -- весь путь его "познания" проходил сам (с коллегами). Во-вторых, мне кажется я использовал его фичи только после их познания/узнавания и у меня не возникало потребностей в том что не знал. Возможно просто везло, а не как новичкам приходящим в команду и которых сразу бросают в пучины git rebase. Плюс мне кажется что на меня снизошло какое-то озарение после прочтения: http://www.ftp.newartisans.com/pub/git.from.bottom.up.pdf после которого git выглядит чрезвычайно простой штукой. git в целом и есть простая нехитрая и незатейливая штука. В нём немного примитивов и действий как таковых. Просто десятки команд это помощники для разных ситуаций. Это сплошной сахар. Одно и то же действие в git можно выполнить, зачастую, тьмой разных способов (наборов команд). У людей даже разные привычки как и что выполнять, хотя результат будет один. А возможно и не один, но в одном случае будет какой-нибудь конфликт в файлах, а в другом уже нет. И всё это создаёт сложности (видимость), но на самом деле никакой магии нет. Я не использовал ни Mercurial (только hg pull/clone), ни Bazaar, ни Arch (на который вроде как и забили), ни Darcs. Читал про них. Mercurial выглядит чище и проще, не является нагромождением всего и вся раскиданным и пересекающимся в разных командах. Но про него от очень опытных пользователей, которые и хорошо умеют git, наслышан про его негибкость и сложности делать относительно сложные вещи. Для новичков Mercurial, насколько понимаю, хорош, но для людей которые чётко понимают что хотят сотворить с историей коммитов -- он будет занозой. Просто наслышан о таком мнении от самых разных опытных людей, которые в итоге переходят на git. А ещё отдельная боль с git-ом это Github. Точнее проблема с людьми, упорото считающих что git и Github это синонимы. Github закрывает репозитории? А, нам всем конец, всё пропало, как жить дальше!? Только ленивый не напоминает в комментариях всяких ресурсов что git как бы децентрализованная система. В общем, git штука с большим порогом входа, в том числе из-за неряшливых ко��анд, но очень мощный инструмент. И из-за своей мощности (возможностей тасовки и вообще работы с коммитами) он стоит изучения/использования. Можно не знать и 90% всех его имеющихся команд и их опций и отлично жить с ним.
From: Алексей Date: 2020-11-07 19:20:50Z > Github закрывает репозитории? А, нам всем конец, всё пропало, как жить дальше!? Только ленивый не напоминает в комментариях всяких ресурсов что git как бы децентрализованная система. Так в том-то как раз и проблема, что это децентрализованная система. И потому повторить на своём собственном сервере привычную модель Github, когда все обращаются к центральному репу, да ещё и с разными правами доступа, не так-то просто. Git на подобное попросту не рассчитан. Тут даже поднять Git-сервер на несколько пользователей с разными правами доступа можно только через разного рода костыли типа gitolite. А уж сделать так, чтоб pull'ить могли все желающие, а push'ить только те, у кого ключи - это вообще что-то настолько нетривиальное, что я даже с ходу не соображу, как такое на сервере можно настроить.
From: Sergey Matveev Date: 2020-11-07 19:39:08Z
Сгенерирован: SGBlog 0.34.0