Комментарии 84
Итак, вы думаете, что знаете Git?
Даже на полсекунды так никогда не думал.
Что-то мне подсказывает, что эту (как будто нарочно максимально запутанную) систему не знает почти никто.
Принудительный безопасный пуш
А можно пояснить зачем делать принудительный пуш, если ты не хочешь затереть историю в ремоут репе? Можео же делать простой пуш, и если там чужие коммиты он поругается.
Такое может пригодиться, если применялась операция rebase
Ну, зачем может понадобиться форсить пуш тогда, когда точно хочется затереть историю я знаю. :) Мне любопытен сценарий, когда захочется затереть историю в ветке с которой активно работает несколько человек.
Ветки с которыми активно работают разные люди, это мастер и всякие релизные, их ребейсить никто не будет. В исключительных случаях, гораздо безопаснее в такую ветку замержить основную ветку отдельным коммитом, который всегда можно будет потом отменить.
В свои личные ветки, которые потом планируется куда-нибудь мержить, по-идее посторонних почти никогда не бывает. Бывают очень редкие ситуации, например, человек ушел в отпуск, а очень надо замержить то, что он делал, предварительно доделав, но и тогда нет никакой активной работы в одной такой ветке от нескольких людей, с веткой так и работает один человек.
Если вздумал дополнить только что сделанный коммит через amend, и надеешься что прокатит это запушить. Я периодически таким успешно пользуюсь
Но зачем это делать в ветках с которыми активно работают разные люди? Ну или скорее так: зачем у веток, с которыми идет активная работа нескольких пользователей одновременно, разрешать прямые коммиты? Обычно в такие ветки разрешают коммитить только пул-реквестами.
Например у нас есть ветка для патчей с которой собирается пайп на тест сборку. Его переодически нужно обновлять на мастер. Делаем ребейс и форс пуш. Заливаем комит с патчем - пайп пошёл собирать версию для тестов
Это может быть ветка-пулреквест как раз, которую готовят к мержу в мастер. И коммитит в неё разработчик и devops, последние фиксы какие-то, чтобы всё точно завелось после мержа
Ну, зачем может понадобиться форсить пуш тогда, когда точно хочется затереть историю я знаю. :) Мне любопытен сценарий, когда захочется затереть историю в ветке с которой активно работает несколько человек.
Несколько человек поторопились и вмержили с кодом: сборник анекдотов на насущную политическую тему, видео с котом, пароли от сервера. Да мало-ли ситуаций когда нужно провернуть фарш обратно, переписав часть истории? https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository
ну ты случайно намусорил коммитами и хочешь их засквашить.
А кто-то паралельно в твою ветку пушнул что-то. Ты не хотел ему мешать, ты свое хотел почистить
Ну, я фанат git --amend. Когда ты уверен, что последний коммит твой, и ты что-то подправляешь - это удобно. Но ты никогда не можешь быть уверен, а с таким вот пушем с проверкой это становится безопасным.
Ну и rebase опять же, зачем всякие "fixed fix" коммиты тащить, если их можно сразу слить у себя.
sc— мои инициалы, чтобы можно было группировать по тому, где чья ветка. Много дурацких метаданных ради попытки зазубрить ветки просто потому, что они так перечислены....
Что действительно нужно сделать, так это проверить, не пушил ли кто-то другой, и пушить принудительно, только если ответ — «нет».
И всех этих проблем можно избежать, если выделять по репозитарию на разработчика. Почему так не очень принято делать - до сих пор не понимаю.
Все хобби-разработчики так и делают. Но так можно делать только небольшие проекты, которые в одну харю. А если в две хари - то уже репозиторий надо на двоих...
то уже репозиторий надо на двоих...
Это почему? Каждый делает локально и пушает в свой удаленный. Потом обмениваемся запросами "забери/замержи ветку XYZ из моего". Вся разница - что просто вместо имени ветки еще префикс репозитария есть.
Если проект сильно большой - то у инженера интеграции тоже свой репозитарий есть, где он работу всех в одну кучу собирает, тестирует и потом пушает. Откуда уже все остальные объединённый код себе подтягивают.
А чем это принципиально отличается от того, когда каждый играется в своей ветке (branch)? Так же, никто никому не мешает, пока каждый в своей ветке. Но при слиянии и конфликтах - уже геморрой.
Тем, в описанной ситуации играются не в одной ветке. И возникает проблема помнить, где чья. (Ну, по описанию)
А так - все понятно. В моей репе лежат только мои ветки. В remote/vasya - ветки Васи.
Почему какой-то лишний гемморой при слияниях и конфликтах - непонятно.
git merge vasya-branch работает так же как git merge remote/vasya/branch
С тем же успехом вы можете просто называть ветки vasya/branch и никаких remote'ов.
Да. Верно. Но в ситуации с несколькими репозитариями можно иметь свой main, который делать публичным по завершению работ.
'Я тут багфикс ISSUE-123 в main слил, посмотри и забери, pls'.
В ситуации одного репозитария такие операции приходится делать в какой-то другой ветке, чтобы недотестированные и недоревьювленне изменения никто к себе не забрал как готовые - в ветке main же находятся.
Для этого придумали всякие git-flow, github-flow, gitlab-flow.
Чтоб ветка master была одна, репозиторий тоже был один, и было единственное место, куда складывается проверенный и оттестированный код.
main
(в сторону) блин, да что же их "Хижина дяди Тома" остальным-то жить спокойно не даёт?
Чтоб ветка master была одна, репозиторий тоже был один, и было единственное место, куда складывается проверенный и оттестированный код.
Тут есть некое противоречие, когда репозитарий один.
В момент, когда мы в первый раз собираем то, что хотим сделать релизом, из комммита xyz - он на main быть еще не должен (потому что не оттестировано и неизвестно, одобрим ли мы получившееся). Но после успешного - тот же самый коммит уже должен быть на main-е. Что невозможно в случае одного репозитария.
Тот же самый - потому что если мы делаем слияния в main после тестирования - это будет уже другой коммит и все артефакты, по хорошему, нужно пересобирать уже из него. И собранное окажется уже не оттестированым. Порочный круг.
У вас какая-то своя политика работы с гитом, которую вы пытаетесь выдать как нечто общепринятое. Вам даже точно сказали что погуглить...
В вашем случае нужна develop ветка отдельно от мейн
Я как раз не пытаюсь. Я удивляюсь и пытаюсь понять, почему так не делают.
В вашем случае нужна develop ветка отдельно от мейн
Почему не develop репозитарий?
Вам даже точно сказали что погуглить...
Вот именно после гугления оно и сходится.
Потому что 'куда складывается проверенный и оттестированный код' - и дальше у меня аргумент-вопрос по поводу того, какой именно ветке должен принадлежать коммит, который мы только что собрали до тестирования и после.
Ну вот в этом самом git flow:
Тот коммит, который помечен тегом 0.2 и из которого мы только что собрали приложение, но еще не оттестировали - что с ним происходит, когда тестирование не пройдет? По определению ' складывается проверенный и оттестированный код', его надо бы из этого master как-то убирать, нет?
А если мы собираем и тестируем не из этого коммита, а из вышестоящего в hotfix - то почему тегом 0.2 помечается не то что собрали, а что-то после мержа, что, вообще говоря, протестированному коду не соответствует.
Что вам мешает сначала тестировать, а потом тегать?
То, что даже без тега коммит будет на master, что противоречит вот этому самому 'складывается проверенный и оттестированный код'
А если таковым считается только то, что под тегами - то и master значительно теряет в смысле. Этот тег просто на коммит в hotfix поставить можно было. Ну а саму ветку hotfix-xyz просто после этого удалить.
даже без тега коммит будет на master
Коммит сначала тестируется на этапе красного кружочка. Весь код совпадает с мастером. Верно? Верно.
Потом переносится в мастер.
Итого в мастер помещен только протестированный код.
Можно было поставить тег на ветку с хотфиксом? Наверное можно. Нужно ли? Нет не нужно
Коммит сначала тестируется на этапе красного кружочка. Весь код совпадает с мастером.
Не понял, с чем совпадает? Та же изменения по хотфиксу? Т.е. с 0.1 оно не совпадает. А 0.2 еще нет.
А утверждать, что после того, как мы 0.2 создадим будет совпадать с красным кружочком - ну может быть, если аккуратно.
Но вот артефакты, собранный из 0.2 точно с артефактами, собранными из красного кружочка, не совпадут. Хотя бы по мета-информации вида 'приложение собрано из коммита номер...'. А тестировали мы именно их, а не то, что из 0.2 можно собрать.
Не может быть, а точно совпадают. Диффа нет. Артефакты и код одинаковый. Если приложение\программист зачем-то залазит в то как код хранится - это его проблемы.
Если приложение\программист зачем-то залазит в то как код хранится - это его проблемы.
А это не приложение и программист лезет. Это отдел тестирования. "Мы вот протестировали то, что вы из(спрашивает приложение, откуда оно было собрано) коммита xyz собрали. Можно вот эти все бинарники версией 0.2 делать ибо дефект там починен. А вот то, что собирается из тега 0.2 после вашего слияния - это непонятно что и его заново тестировать надо."
Там же fast-forward будет — хэш не изменится. Аналогично и с 1.0
Вот в develop оно будет вмержено, но код из этой ветки еще сотню раз будет протестирован, прежде, чем случится все остальное.
Там же fast-forward будет
Fast-forward на картинках слияний выглядят иначе.. И тег в этом случае должен рисоваться сразу на ветке hotfix и на master. Или как-то иначе показываться, что это один и тот же коммит.
Но аргумент принимается с поправкой на то, что стандартная картинка сильно в заблуждение вводит.
Аналогично и с 1.0
И одновременно все зелененькие из 'release branches' визуально окажутся на master. Ну да, проблема на самом деле в том, что в git 'настоящих' веток нет. Но тем не менее - снова получим (визуальное?) противоречие с тем, что в master лежит 'проверенный и оттестированный код'.
моей репе лежат только мои ветки. В remote/vasya - ветки Васи.
Не обязательно. Если васина фича зависит от моей, а моя - от васиной, то у каждого в репе будут чужие ветки и по два remote, свой и товарища
Приходим к выводу, что двоим-троим всё же удобнее в один реп коммитить, а не в три.
каждого в репе будут чужие ветки и по два remote, свой и товарища
Выделенное - не сильно нужно. Они и так есть, в соответствующем remote живут. Или имеется в виду, что захочется закоммитить в чужую фич-ветку? Тогда да, у каждого будет по ветке на фичу. И пушать будет каждый в свою. А товарищ-'владелец' фичи будет оттуда изменения забирать и к себе сливать, после того, как убедится, что все правильно.
Если моя фича зависит от васиной, то, чтобы проверить свои результаты, я должен буду притянуть в свой форк васину ветку, ребейзнуть свои коммиты на неё или слить мою ветку с васиной.
Если Вася где-то не прав, и я могу это исправить, то получается еще одна ветка.
должен буду притянуть в свой форк васину ветку
Это сделает fetch соответствующего remote. Не обязательно же ее делать видимой в основном своем списке по умолчанию.
ребейзнуть свои коммиты на неё или слить мою ветку с васиной.
Ну да. Но наличие васиной ветке в непосредственной видимости в виде '/vasya/feature-123' общего репозитария - никаких преимуществ не создают.
Вот у инженера интеграции и получается описанная изначально ситуация.
Кстати, не подскажете, в форках репозиториев лежат копии файлов или ссылки на оригинал?
А то диски на сервере всё-таки не резиновые, и если проект сильно большой, это может быть критично.
Кстати, не подскажете, в форках репозиториев лежат копии файлов или ссылки на оригинал?
Насколько я знаю, гитовые репозитарии хорошо дедуплицируются. Сам GitHub с тысячами форков - как их хранит. Что-то я слегка не верю, что там везде копии.
Это GitHub так вывернулся. Про Gitlab, Bitbucket, Gitea, gogs и прочие хостинги мне ничего не известно.
В gerrit, насколько я помню, вообще нет понятия форка.
Предлагаете заинтересованным покупать GitHub Enterprise?
Это GitHub так вывернулся. Про Gitlab, Bitbucket, Gitea, gogs и прочие хостинги мне ничего не известно.
Не совсем. Эта возможность более-менее встроенная, если аккуратно делать.
Вот как у GitLab-а.
выделять по репозитарию на разработчика
Т.е один проект (репозиторий) - один исполнитель?
Что предлагаете делать в случае, если проект большой, и одного исполнителя мало?
Что предлагаете делать в случае, если проект большой, и одного исполнителя мало?
У каждого исполнителя в рамке проекта - свой. Плюс разные служебные. В терминологии того же GitHub - форки. Ну вот как он показывает. И слияния потом идут не в пределах одного репозитария а между ними.
Преимущество, например - каждый разработчик может всякий недодел в свой пушать с целью 'не потерять, что сделал', но это не будет замусоривать основной-релизный, с которого все тянут опубликованные окончательно принятые изменения.
И с тестированием чуточку удобнее в смысли 'не мешать другим'. Релиз-инженер/команда может очередную 'версия X.Y.Z' на ветке 'main' слить, собрать, отправить на тестирование. И только если все тесты пройдут - сделать этот новый main публичным.
Думаю, что форки - это всё же не для командной работы, а для возможности иметь своё "такое же, но с перламутровыми пуговицами". Команды и на гитхабе в один реп коммитят.
А иначе тупо не понятно, где автора искать.
Это чисто вопрос терминологии.
Сделал себе 'перломутровые пуговицы' и предложил в апстрим. Там посмотрели и влили (или не влили) в основной репозитарий - вот оно не то же самое, что в рамках одного проекта 'фичу' добавить?
В общем случае нет, не то же самое. Git изначально задумывался как инструмент для коллективной работы над одним кодом.
Кстати, про ci-build еще забыли. Его обычно для репозитория индивидуально настраивают. Т.е. для каждого форка своё придётся делать.
Я не отрицаю, что над одним проектом можно вести работу в разных форках, и потом как-то их сливать. Но мне кажется, что форк в данном случае лишняя сущность. И так у каждого участника по копии уже есть.
Однако, и всю винду целиком в один монореп запихивать - это тоже очень странно.
Подход Гугла к хранению исходников Android мне нравится больше. ROS2 примерно так же хранит свой код (https://github.com/ros2). Там пачка относительно небольших репозиториев, в каждом хранится отдельная логически законченная часть прокета. И есть https://github.com/dirk-thomas/vcstool который выкачивает или переключает всю эту пачку разом на нужные коммиты, в зависимости от того, что сказано в YAML с конфигурацией
В общем я за разумное укрупнение или дробление там, где это реально нужно.
Я пропустил звено в переходе от форков к монорепозиторию с виндой, а отредактировать комментарий уже не получается.
Думаю, что все эти пляски с сортировкой веток и коммиттеров связаны как раз с этим. В MS запихнули все исходники винды в один git-репозиторий, и под это дело допилили виртуализацию staging area, сортировки и sparse checkout.
Git изначально задумывался как инструмент для коллективной работы над одним кодом.
Именно. Над одним кодом с кучей репозитариев (в различной мере клонов друг друга) в разных местах. Вот и будем пользоваться возможностью делать кучу, а не будем придумывать лишнюю сущность про naming convention для веток, чтобы разработчики в ветках не путались, где чья и про что.
Я не отрицаю, что над одним проектом можно вести работу в разных форках, и потом как-то их сливать. Но мне кажется, что форк в данном случае лишняя сущность.
Мой аргумент в том, что слияние что из локальной ветки, что из remote - выглядят и работают практически неразличимо. Поэтому 'как-то' - несколько не то слово. Как раньше сливали, так и продолжать делать.
Кстати, про ci-build еще забыли. Его обычно для репозитория индивидуально настраивают. Т.е. для каждого форка своё придётся делать.
Это, пожалую, аргумент за то, чтобы использовать разные репы - что у каждого сборку можно настроить отдельно. У разработчика по какой-то функциональности - сборщик линкует разные заглушки. У пре-релизного форка команды тестирования - все параноидные тесты включены на максимум. И так далее.
В крупных компаниях практикуется и для командной работы. В репу проекта напрямую коммитить могут только несколько админов, разработчики форкают проект к себе, там у себя пилят какие им нравится ветки и делают пул-реквесты из своей репы в основную репу. Я видел такое в нескольких компаниях. Автора искать очень легко, во-первых заапрувленный пул-реквест мержит как правило автор, во-вторых все коммиты пул-реквестов содержат его номер, по которому легко посмотреть что за ПР, что за коммиты в нем были и тд.
Мне кажется основная цель это держать главный репозиторий проекта более-менее чистым, где мастер и только релизные бранчи, оно сильно удобнее чем когда несколько сот человек могут работать и либо за каждым кому-то надо бегать и ныть, чтоб позакрывал забытые ветки, либо забить и иметь распухшую репу с тысячами веток.
Мне кажется GIT - интересная иллюстрация, как относительно простой проект, очень удобный для небольших разработок малой командой вдруг вырастает, вырастает, вырастает - теперь боингу, сбербанку и кока-коле он стал удобнее, а вот маленькому разработчику - мешает.
Зачем они это сделали? Неужели многие разработчики в малых командах страдали от нехватки этих фич?
очень удобный для небольших разработок малой командой вдруг вырастает
Можете пояснить? Вы ведь сейчас про времена, когда не было никаких хостингов, а разработчики отсылали патчи через почту?
Git возник как инструмент для разработки Linux. И большая часть его возможностей вытекла из потребностей сообщества, а не корпораций.
Я не про корпорации тут, а про размер и сложность проектов. Сам Linux kernel - это проект, масштабу которого любой Боинг позавидует. Я вот распаковал-посчитал. 1.5Gb сорцов! 87 тысяч файлов. А сколько разработчиков - наугад тыкаю: пусть 5000 разработчиков.
Конечно, скорее всего, удобная система контроля версий для такого проекта будет отличаться от того, что удобно команде из 10 человек с проектом из 200 файлов. Потребности этого крошечного сообщества (10 человек) очень сильно отличаются от потребностей гигантского проекта на 5000 человек, и инструменты им нужны разные. Или - урезанная версия того же инструмента.
Да, может быть хорошо, что git - это звездолет, столь мощный, что им можно тащить даже огромный проект уровня linux kernel. Но, блин, сейчас поглядел - оф. учебник "Pro Git" (на git-scm.com) - это 500 страниц!! Почему на tar или wget нет учебника на 500 страниц?
И давайте честно - 99% наших операций - это git add/commit/push. Ну ок - еще branch/merge. Мне кажется, что гит из простого удобного механизма (мясорубки) превратился в звездолет, в котором есть пищеблок и там есть мясорубка. И единственный способ не сойти с ума от ужаса проблемы (а программист ведь должен не только git знать) - это забыть про все "ненужные" функции и пользоваться им в объеме 10-минутного quick-start guide. Но даже чтобы не пользоваться "ненужной" функцией - нужно как-то ее в голове иметь, примерно понять - это отнимает ресурсы.
Мне кажется, достаточная альтернатива git'у должна иметь несколько простых use-case, и усваиваться за те же 10 минут, ну за час. Вы верно подметили - даже огромный по меркам конца 90-ых готов проект ядра ОС Линукс вполне жил на patch. Неправильно, что инструмент, делающий достаточно простую штуку - столь сложен.
это 500 страниц!!
Из которых 300 страниц это "как поднять свой git-хостинг" и 100 страниц картинок.
пользоваться им в объеме 10-минутного quick-start guide
Ну большинство так и пользуются гитом, умея только нажимать готовые кнопки commit/push/pull в ide. Однако можно сильно упростить себе жизнь, если познакомиться с git поближе.
> Вы верно подметили - даже огромный по меркам конца 90-ых готов проект ядра ОС Линукс вполне жил на patch
Авторы формируют через git format-patch патчи, отсылают их по почте в список рассылки, комиттеры же из почты их забирают.
Так до сих пор ведется разработка и Linux и самого git.
Так до сих пор ведется разработка и Linux и самого git.
Авторы (или кто-то за авторов) объясняют это тем, что git не вывозит такого размера кода. Точнее, раньше не вывозил, а теперь может.
Вот тут пишут, что MS все исходники винды в git monorep запихнула. Для этого все нововведения и понадобились
500 страниц - какая мелочь ))
https://habr.com/ru/companies/dcmiran/articles/493018/
Очень интересная статья. Выходит - ни один человек в мире браузеров не знает в полном объеме, что он творит. Меня просто вышибает эта мысль. Каждый действует как-то по-умолчаниям, по-наитию, по-ощущениям.
Я как раз вчера сталкивался с проблемой, что один код выдавал ссылки на файлы с пробелами через +. То есть "Война+и+мир.pdf". А это неправильно, потому что пробел кодируется плюсом только в application/x-www-form-urlencoded контенте. И я не мог понять, почему так - разбирался. И они дураки, и я дурак (раз не знал заранее) и все дураки. И при этом мы строим какую-то огромную вавилонскую башню, без понимания. Вернее, она как-то сама строится. На стройке хотя бы прораб понимает, а остальные его слушаются. У нас же - никто не понимает.
Но, возвращаясь к git'у - мне кажется, его место в жизни разработчика должно быть гораздо скромнее. Музыкант может загружать свои песни в Интернет - но не знать ничего про HTTP. Домохозяйка открывает кран и набирает воду в кастрюлю - ничего не зная про насосы, сантехнические фитинги и очистку воды. Водитель поворачивает ключ и машина делает "вжжжж" - водитель не знает, каково содержание углерода в стали поршней (а оно там строго определенное и по какой-то причине!). Но все эти внутренние детали удается удачно скрыть - и это правильно.
Музыкант может загружать свои песни в Интернет - но не знать ничего про HTTP
Да, но. git это не средство хранения, а средство разработки. Он позволяет собрать из нескольких работ разных авторов цельный продукт (код). При этом разные версии продукта будут иметь разный функционал. В хотфикс например пойдут только критичные баги, в новый релиз пойдут и баги из хотфикса и новые фичи. Вы когда делаете push, то вам тоже не нужно ничего знать про http.
На примере музыканта: ему потребуется как минимум знание программы для сведения разных партий. Просто обычно этим в музыкальной индустрии занимается отдельный человек.
Я не спорю, и то что он важен и то, что он умеет много разных функций. Но мне кажется, почти в любой сфере есть сложные продукты, и простые. Вот сходу - языки программирования. Раньше на С было очень много проблем с переполнением буфера, с записью за границы массива, с утечками памяти. Каждая из этих проблем была не "во славу Сатаны", а технически обсусловлена.
А потом появились интерпретируемые языки и выяснилось, что можно без всех этих сложностей. Они не во всем лучше С, у С осталась своя ниша, но во многих сферах - можно все гораздо проще делать, быстрее, дешевле.
Усложнять легко, упрощать сложно. Но периодически появляются новые технологии, по которым оказывается, что то что вчера было сложно - сегодня можно.
Я не могу сказать, как должна выглядеть более простая система управления версиями (в том и проблема, что 90% успеха - это правильно увидеть проблему с нужной стороны). Но когда-если такая новая система будет, нам через какое-то время это все будет казаться простым и естественным как сборщик памяти в интерпретируемых языках.
Про это сложно говорить, это скорее разговор о "предчувствиях", примерно как футуристические прогнозы.
Вся сложность git и других систем управления версиями обусловлена в первую очередь сложностью разрешения конфликтов.
На данном этапе все ещё приходится это делать руками. Если б можно было это автоматизировать, то можно было бы с задачами работать на более высоком уровне абстракций, без погружения в код.
Хочу вот эту задачку в этот релиз - нажал кнопку и оно заработало.
На практике же могут возникнуть нетривиальные конфликты. В ветку мог быть вмержен мастер, и этот мерж-коммит притащит с собой код, которого в задаче не должно было быть.
Поэтому имеем в арсенале помимо merge ещё и rebase, который, как я считаю, должен знать каждый разработчик.
Для успешного использования гита достаточно разобраться с commit, add/reset, push/pull, tag, checkout/branch, merge-base, merge и rebase + merge-tool Это покроет 99% потребностей любого разработчика.
Это изучается за пару вечеров. (Изначально команд было меньше, но, подумав, я добавил ещё :-)
Все остальное в git либо добавляет комфорта при работе (например stash), либо используется очень специфичных случаях (например filer-branch).
Итого, что я хочу этим сказать. Да, git сложный. Но это лишь потому, что он решает сложную задачу.
Да, у git крутая кривая обучения, нужно сразу много чего знать, что бы нормально им пользоваться. Я при первом своем знакомстве с ним клонировал репозиторий несколько раз заново, потому что "что-то нажал и оно сломалось".
Однако этот пробел в знаниях заполняется за короткое время.
У git хорошая документация, но она абсолютно бесполезна для новичка, опять же из-за кривой обучения. Pro Git тут очень помогает.
На самом деле, для "обычного пользователя" git не сложнее чем тот же svn/hg. Для того чтобы с ним работать, достаточно базовых представлений о том, что такое репозиторий, что такое файл, что такое коммит, что такое ветка. Как вы верно сказали, clone/pull/add/commit/checkout/push/merge покрывает 99% нужды 99% разработчиков (я тут даже rebase опустил).
И собственно, если человек имеет представление о том, как работает фиксация изменений, ака коммит, на логическом уровне, а не как там считаются хэши объектов, как они там хранятся и т.д., то и не возникнет никаких проблем с cherry-pick, stash, rebase и т.п.
git устроен сложно, в нем огромное колво инструментов и возможностей. Но взять к примеру фотошоп -- он тоже сложный и в нем много возможностей, но никто ж не жалуется что в нем сложно обрезать и повернуть картинку :)
История про сотни веток какая-то притянутая. Ну 10 у меня веток бывает, ну 15 если все очень плохо. Большее количество вариаций уже мозг не вывозит, и не в сортировке проблема
Во многих продуктовых репозиториях могут быть сотни веток: каждый релиз новой версии - своя ветка куда будут коммититься багофиксы. Только что глянул, у нас в одном из рабочих репозиториев 278 открытых веток.
Другое дело, что локально забираешь из основного репозитория только мастер и изредка ветку какого-нибудь релиза, когда надо пул реквест на фикс сделать.
Один из моих проектов с командой из 5-6 человек за 3 года оброс 400 с лишним ветками. Размер репа составлял больше 1Гб.
Другой проект длился 6 лет, разрабатывался двумя командами из 8 и 11 человек. Тоже несколько сотен веток запросто накопилось. Два или три раза переезжали в другой репозиторий: останавливали коммиты в текущий, переводили его в read-only и заводили новый из текущего слепка. В этом случае еще большие бинарные файлы (ассеты для UE4) и Git LFS прибавились.
вы их что ли не удаляете после слияния?
После слияния - удаляли, разумеется. Часть руками, часть автоматом. Если бы не кнопка "Delete merged branches", веток было бы еще больше.
Еще были эксперименты в отдельных ветках, которые так никуда и не пошли. Я несколько раз кликал клич, мол, "ув. коллеги, удалите всё, что вам не нужно". Что-то удаляли, что-то оставалось ("оставь, я потом доделаю!". "потом" не наступало).
400 долгоиграющих веток? У вас проблемы с организацией воркфлоу, совершенно точно, это на 5-6 человек то.
Нет, просто забытых. Я ж говорю, человек просил меня означенную ветку оставить, т.к. там было что-то для него ценное, что он собирался доделать как-нибудь потом, и вот это потом никогда не наступало.
И проблем больше нет. Во-первых, проект давно завершен, во-вторых, я там уже не работаю.
Проблемы с организацией воркфлоу были, это точно. И обилие веток было наименее существенной из них. Еще имелась копия нашего репа в Perforce, с довольно сложными правилами коммитов туда и периодически прилетающими правками оттуда, которые как правило всё ломали. Я с со всем этим пытался бороться, но встречал непонимание со стороны остальных, вызванное, в частности, недостаточным умением членов команды работать с git (как я сейчас думаю, оглядываясь назад).
Выгорел и ушел в другой проект. Теперь вообще работу поменял.
Видимо, речь про Microsoft и запихивание всех исходников Windows в монореп git. Там в последнем предложении ссылка на английскую статью про это.
Советую ещё посмотреть оригинальное выступление на Fosdem 2024, автор ещё и прекрасный лектор (и с чувством юмора у него норм)
Исходное сообщение удалено
Не разобрался изначально...)
думаю я знаю все, что мне нужно, а для всего остального существует параметр --foce ;)
Есть еще один workflow, называется “stacked PRs”:
постулируется, что 1 коммит = 1 PR (т.е. веток как таковых нет, есть просто стек коммитов поверх мастера, и можно редактировать незамердженные еще коммиты-PRы прямо в середине)
код вмердживается в мастер как можно скорее, мелкими порциями
незавершенные (при этом проходящие CI) вещи тоже вмердживаются, но покрываются if-ом с feature-флагом (т.е. они невидимы пользователю)
Эту схему используют некоторые компании в FAANG, она на мой взгляд крайне экономит время, особенно когда кода пишется много, и разработчиков тоже много. Я полгода назад написал утилиту, которой мы пользуемся в компании, она поддерживает бесшовную интеграцию stacked PRs с GitHub (но пока не анонсировал): https://github.com/dimikot/git-grok
Но теперь мы можем попросить git помочь: сортировать ветки по
objectsize,authordate,committerdate,creatordate, илиtaggerdateопцией--sort, или установить значение опции по умолчанию параметром конфигурацииbranch.sort
Понимаю, что сейчас напишу очень спорный комментарий, но мнение своё выскажу. На дворе 21 век, мы через голосовые интерфейсы общаемся с генеративными сетями, вытаскивающими для нас информацию из поисковиков - но при этом с гитом нам всё равно предлагают общаться через консоль? Реально вы серьёзно? Не для автоматизации рутинных действий и последовательностей команд в "моё утро начинается с кофе и гит фетч ребейз", а вот для всего остального? И мне действительно предлагают помнить или искать эти опции у сортировки по разным атрибутам? Или может всё-таки просто мышкой сортировать и фильтровать табличные данные, к чему (к работе со структурированными табличными данными) должен быть автоматически привычен любой сегодня человек? Оно ведь ещё и запомнит, по какому столбцу я сортировал и порядок сортировки, безо всяких параметров конфигурации...
Следующая интересная вещь, которую добавили в git совсем недавно ... --force-with-lease
Судя по всему эта опция присутстует минимум с 2015 года.
Закоммичена была ещё в 13 году :)
Итак, вы думаете, что знаете Git? Часть вторая: новое в Git