Если разработчик лично предпочитает merge, но на текущем проекте всем нужно делать rebase, то в таком случае данный метод это очень хороший компромисс.
И я согласен, что rebase требует большей квалификации и понимания, чем merge. И что rebase противоречит оригинальной идеологии git, что все коммиты должны быть иммутабельны.
Допустим, общая ветка (upstream) это develop, есть три варианта насколько строго требовать корректность коммитов в репозитории на сервере:
develop должен быть корректным в любой момент времени.
develop + feature ветки должны быть корректными в любой момент времени.
все коммиты в истории всех веток должны быть корректными.
Первый вариант наиболее распространенный, дает больше свободы разработчикам и меньше давит на них.
Второй вариант имеет смысл если над feature веткой работают два разработчика одновременно, или когда ветка отдельно деплоится для тестирования.
Третий вариант самый строгий. В общем он естественный если только делать merge. Но в случае rebase всегда гарантировать синтаксическую и логическую корректность каждого rebase-нутого коммита становится очень сложно.
Мой метод rebase-а подходит для 1 и 2 вариантов: upstream всегда рабочий, все мерджи в upstream несут только корректный дифф, feature ветки тоже корректны в любой момент времени (можно сбилдить и протестировать).
Минус моего метода в том, что если сделать checkout какого-то промежуточного коммита, то он может не сбилдится, то есть 3 вариант отпадает. Только как правило в этом нет необходимости.
Есть несколько моментов. Допустим, на ветке 15 коммитов и она готова для merge-а. В общем случае, заранее неизвестно будут ли конфликты и в каком объеме. Если история коммитов не важна, то да, можно просто сквошить все 15 коммитов в один большой коммит, и там уже не важно merge или rebase, это будет один и тот же большой конфликт.
Но в большинстве случаев история отдельных коммитов важна, а точнее, их диффы и описание диффов. Однако каждый коммит может привести к отдельному конфликту при rebase. Обычно эти конфликты исправляются вручную по мере продвижения rebase-a, и целью является новый корректный код , что часто приводит к потере оригинального кода. Получается, что описание диффа старое, а код в нем новый, но это является нормой в классическом подходе. Из других минусов по сравнению с merge - нужно больше времени на исправление конфликтов и сложность в оценке суммарной работы.
Смысл данного метода в моментальной оценке работы по исправлению конфликтов и максимальная экономия времени на исправление, это достигается за счет merge-а. При этом сохраняется вся оригинальная история коммитов и оригинальный код, даже если он уже устарел. Это подходит не всем, и тогда нужен обычный rebase.
Обратный дифф не вычисляется, точнее после безусловного ребейза проект полностью заменяется корректным состоянием после сделанного merge-a, поэтому возникает дополнительный коммит. Но его легко убрать, соединив с предыдущим коммитом.
Xeon / EPYC это обычные CPU, поэтому скорость генерации токенов будет слишком медленная, по несколько секунд на одно слово, тогда как Apple Silicon это несколько слов в секунду. Энергопотребление тоже не в пользу Intel / AMD.
Фактически, компьютеры от Apple - единственные на рынке с большим объемом RAM памяти, которая доступна не только CPU, но и GPU. В общем, это и есть unified memory и это идеально подходит для локального LLM inference: чаты, кодинг.
Вместо git push --force лучше всегда делать git push --force-with-lease. В чем разница? Допустим вы с Васей работаете над одной общей веткой и хотите исправить текст нового коммита, который вы только что отправили, но если Вася в это время отправил свой коммит, то git push --force просто молча выкинет его коммит из истории на сервере, потому что ваш репозиторий его не видит. Тогда как git push --force-with-lease запрещает переписывание ветки, если там есть новые чужие коммиты. Я лично использую алиас git pf.
Сделать сразу грамотную архитектуру, писать только качественный код обычно нереально. Настоящие бизнес требования, которые приносят прибыль, находятся только после множества релизов.
Согласен, я сам разработчик, так всегда и происходит. Только я никого не оправдываю и не обвиняю. Замедление скорости доставки под грузом старой архитектуры и качества кода - это, к сожалению, нормально. Бизнес редко выбирает риск переписывания системы с нуля.
Это практически все случаи, когда кому-то платят деньги за написание кода. В бизнесе компания вынуждена зарабатывать деньги, а расходы на разработку ПО - это большая и серьезная статья расходов, которую она стремится минимизировать. Только корпорации могут себе позволить такие большие затраты.
Именно! Инженерам нужен длинный горизонт планирования, но в бизнесе ситуация постоянно меняется и планы тоже. Бизнесу нужны постоянные эксперименты с фичами, чтобы выжить, а инженер хочет неизменность функциональных требований. Это неизбежное фундаментальное противоречие.
Объяснение от обратного. Вот где реально необходимо писать качественный код? Когда цена необратимой ошибки очень высока: медицинское оборудование, ядро платежных систем, управление самолетом и т.д. И тут есть существенный минус: необходимо много времени на серьезный code review, глубокое тестирование перед релизом. В типичном корпоративном бизнесе все наоборот: скорость доставки на порядок важнее, чем отсутствие проблем в коде или архитектуре. Таким образом, это не является существенной проблемой самого бизнеса.
Какой абсолютный минимум объем RAM нужен для такого учебного проекта? И как насчёт сборки под ARM с запуском на QEMU и на физическом железе типа Raspberry?
Интересно, а что будет после его ухода и многолетней диктатуры? Демократия разработчиков? Олигополия больших корпораций? Добавят С++ или ZFS?
Если разработчик лично предпочитает merge, но на текущем проекте всем нужно делать rebase, то в таком случае данный метод это очень хороший компромисс.
И я согласен, что rebase требует большей квалификации и понимания, чем merge. И что rebase противоречит оригинальной идеологии git, что все коммиты должны быть иммутабельны.
Допустим, общая ветка (upstream) это develop, есть три варианта насколько строго требовать корректность коммитов в репозитории на сервере:
develop должен быть корректным в любой момент времени.
develop + feature ветки должны быть корректными в любой момент времени.
все коммиты в истории всех веток должны быть корректными.
Первый вариант наиболее распространенный, дает больше свободы разработчикам и меньше давит на них.
Второй вариант имеет смысл если над feature веткой работают два разработчика одновременно, или когда ветка отдельно деплоится для тестирования.
Третий вариант самый строгий. В общем он естественный если только делать merge. Но в случае rebase всегда гарантировать синтаксическую и логическую корректность каждого rebase-нутого коммита становится очень сложно.
Мой метод rebase-а подходит для 1 и 2 вариантов: upstream всегда рабочий, все мерджи в upstream несут только корректный дифф, feature ветки тоже корректны в любой момент времени (можно сбилдить и протестировать).
Минус моего метода в том, что если сделать checkout какого-то промежуточного коммита, то он может не сбилдится, то есть 3 вариант отпадает. Только как правило в этом нет необходимости.
Я имел в виду, что работа по исправлению конфликтов становится одинаковой между merge и rebase в предельном случае, когда в ветке всего один коммит.
Есть несколько моментов. Допустим, на ветке 15 коммитов и она готова для merge-а. В общем случае, заранее неизвестно будут ли конфликты и в каком объеме. Если история коммитов не важна, то да, можно просто сквошить все 15 коммитов в один большой коммит, и там уже не важно merge или rebase, это будет один и тот же большой конфликт.
Но в большинстве случаев история отдельных коммитов важна, а точнее, их диффы и описание диффов. Однако каждый коммит может привести к отдельному конфликту при rebase. Обычно эти конфликты исправляются вручную по мере продвижения rebase-a, и целью является новый корректный код , что часто приводит к потере оригинального кода. Получается, что описание диффа старое, а код в нем новый, но это является нормой в классическом подходе. Из других минусов по сравнению с merge - нужно больше времени на исправление конфликтов и сложность в оценке суммарной работы.
Смысл данного метода в моментальной оценке работы по исправлению конфликтов и максимальная экономия времени на исправление, это достигается за счет merge-а. При этом сохраняется вся оригинальная история коммитов и оригинальный код, даже если он уже устарел. Это подходит не всем, и тогда нужен обычный rebase.
Обратный дифф не вычисляется, точнее после безусловного ребейза проект полностью заменяется корректным состоянием после сделанного merge-a, поэтому возникает дополнительный коммит. Но его легко убрать, соединив с предыдущим коммитом.
Мне кажется, что это дело вкуса и привычки. Я тоже раньше думал, что тру программист должен выбирать терминал.
Xeon / EPYC это обычные CPU, поэтому скорость генерации токенов будет слишком медленная, по несколько секунд на одно слово, тогда как Apple Silicon это несколько слов в секунду. Энергопотребление тоже не в пользу Intel / AMD.
Фактически, компьютеры от Apple - единственные на рынке с большим объемом RAM памяти, которая доступна не только CPU, но и GPU. В общем, это и есть unified memory и это идеально подходит для локального LLM inference: чаты, кодинг.
Вместо
git push --forceлучше всегда делатьgit push --force-with-lease. В чем разница? Допустим вы с Васей работаете над одной общей веткой и хотите исправить текст нового коммита, который вы только что отправили, но если Вася в это время отправил свой коммит, тоgit push --forceпросто молча выкинет его коммит из истории на сервере, потому что ваш репозиторий его не видит. Тогда какgit push --force-with-leaseзапрещает переписывание ветки, если там есть новые чужие коммиты. Я лично использую алиасgit pf.Сделать сразу грамотную архитектуру, писать только качественный код обычно нереально. Настоящие бизнес требования, которые приносят прибыль, находятся только после множества релизов.
Согласен, я сам разработчик, так всегда и происходит. Только я никого не оправдываю и не обвиняю. Замедление скорости доставки под грузом старой архитектуры и качества кода - это, к сожалению, нормально. Бизнес редко выбирает риск переписывания системы с нуля.
Это практически все случаи, когда кому-то платят деньги за написание кода. В бизнесе компания вынуждена зарабатывать деньги, а расходы на разработку ПО - это большая и серьезная статья расходов, которую она стремится минимизировать. Только корпорации могут себе позволить такие большие затраты.
Именно! Инженерам нужен длинный горизонт планирования, но в бизнесе ситуация постоянно меняется и планы тоже. Бизнесу нужны постоянные эксперименты с фичами, чтобы выжить, а инженер хочет неизменность функциональных требований. Это неизбежное фундаментальное противоречие.
Объяснение от обратного. Вот где реально необходимо писать качественный код? Когда цена необратимой ошибки очень высока: медицинское оборудование, ядро платежных систем, управление самолетом и т.д. И тут есть существенный минус: необходимо много времени на серьезный code review, глубокое тестирование перед релизом. В типичном корпоративном бизнесе все наоборот: скорость доставки на порядок важнее, чем отсутствие проблем в коде или архитектуре. Таким образом, это не является существенной проблемой самого бизнеса.
Все верно, это машинный код, а ассемблерный код - это низкоуровневый язык программирования, чей синтаксис зависит от конкретного железа.
Ссылка на эту задачу на литкоде. Только тут необходимо найти минимальную сумму.
https://leetcode.com/problems/triangle/description/
Доступные языки программирования:
Запуск на ARM со слабым железом, даже слабее Raspberry.
Какой абсолютный минимум объем RAM нужен для такого учебного проекта? И как насчёт сборки под ARM с запуском на QEMU и на физическом железе типа Raspberry?
narod.ru до сих пор работает? Аж олдскулы свело.
Честно говоря, эта юмористическая статья 2016 года не очень актуальна для Кремнивой долины образца марта 2023 года.