Что: 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% всех его имеющихся команд и их опций и отлично жить с ним. ------------------------------------------------------------------------ оставить комментарий: mailto:comment@blog.stargrave.org?subject=Re:%20%D0%9A%D0%BE%D0%BC%D0%B0%D0%BD%D0%B4%D1%8B%20git-%D0%B0:%20worktree%2C%20subtree%20%283605f863a029ba28f8258bc023f94ef1045b20dc%29 ------------------------------------------------------------------------ комментарий 0: From: Алексей Date: 2020-11-07 19:20:50Z > Github закрывает репозитории? А, нам всем конец, всё пропало, как жить дальше!? Только ленивый не напоминает в комментариях всяких ресурсов что git как бы децентрализованная система. Так в том-то как раз и проблема, что это децентрализованная система. И потому повторить на своём собственном сервере привычную модель Github, когда все обращаются к центральному репу, да ещё и с разными правами доступа, не так-то просто. Git на подобное попросту не рассчитан. Тут даже поднять Git-сервер на несколько пользователей с разными правами доступа можно только через разного рода костыли типа gitolite. А уж сделать так, чтоб pull'ить могли все желающие, а push'ить только те, у кого ключи - это вообще что-то настолько нетривиальное, что я даже с ходу не соображу, как такое на сервере можно настроить. ------------------------------------------------------------------------ комментарий 1: From: Sergey Matveev Date: 2020-11-07 19:39:08Z *** Алексей [2020-11-07 22:20]: > И потому повторить на своём собственном сервере привычную модель Github[...] Значит проблема в том, что кто-то к ней привык :-) >когда все обращаются к центральному репу, да ещё и с разными правами доступа, не так-то просто. Git на подобное попросту не рассчитан. Согласен. Но оно и не нужно. Если хочешь чтобы у тебя кто-то забрал изменения: предоставь в своём репозитории, который будет чьим-то remote-ом. Я вообще преобладающее кол-во изменений в сторонние проекты вносил через git-format-patch+git-send-email. >Тут даже поднять Git-сервер на несколько пользователей с разными правами доступа можно только через разного рода костыли типа gitolite. >А уж сделать так, чтоб pull'ить могли все желающие, а push'ить только те, у кого ключи - это вообще что-то настолько нетривиальное Или я что-то недопонял в задаче или это же всё просто: репозиторий для чтения для всех отдаём по git/https. Запись разрешена определённому пользователю/группе доступ к которому через SSH и соответствующие ключи. Если что-то нужно делать не публичным, то ещё один пользователь/группа которая имеет права на чтение директорий/файлов нужных, но не имеет права на запись. Насколько понимаю, как правило анонимных reader-ов много, а коммитеров очень мало -- это без проблем делается обычными пользователями/группами Unix-овыми. Разве нет? Я, по крайней мере, именно так делал. ------------------------------------------------------------------------ Сгенерирован: SGBlog 0.34.0