Git — популярная система контроля версий. В ней атомарное изменение одного или нескольких файлов называется коммитом, а несколько последовательно идущих коммитов объединяются в ветку. Ветки используются для того, чтобы реализовывать новые идеи (фичи).
Случается, что идея оказывается тупиковой, разработчик сворачивает не туда, и возникает необходимость отката к изначальной версии, для этого нужно забыть о новой ветви и переключиться на главную dev или master, и затем продолжить работу как ни в чем не бывало. В этом случае "отросток" повиснет навсегда, как и желание его удалить. Но как удалить, если это часть истории? Этот отросток показывает усилия трудяги-программиста, пусть и тщетные. Так легче отчитываться перед начальством, ведь неудачный результат — тоже результат!
Спешу обрадовать: разработчики Git в 3 версии введут новую команду для замыкания таких беспризорных ветвей. Напомню, что текущая актуальная версия — 2.21.0.
Как использовать эту команду, что она дает и что думают IT компании? Статья отвечает на эти и другие вопросы.
Описание
Теперь можно замкнуть неудачную ветку с одним из предыдущих коммитов. Желтым цветом на рисунках ниже раскрашены дуги замыкания.
Здесь коммит 4 — последний у неудачной фичи. Его замкнули с 1, а затем вернулись в мастер и пошли по другому пути, с коммита 5.
Также можно замыкать коммит в самого себя, таким образом создавая петли:
Можно замыкаться в любой коммит — умный Git сам подсчитает разницу и правильно все объединит:
Как пользоваться?
В команду merge функциональность замыканий не вмержить, так как для первого случая ветвь будет фаст-фордиться, а для второго не будет ничего делать (git already up to date).
Чтобы не менять старое поведение, разработчики решили ввести команду для замыкания:
git closure -s $source_commit -d $dest_commit -m $messageПервым аргументом -s $source_commit задается хеш коммита, из которого нужно протянуть "петлю", а вторым, опциональным -d $dest_commit, задается коммит, в который петлю нужно замкнуть. Если он отсутствует, то замыкание происходит в текущую check-out ветвь. Параметром -m $message задается сообщение замыкания, типа failed feature, revert to origin. Впрочем, доступен и параметр --allow-empty-message, разрешающий коммиты без текста сообщения. По умолчанию Git разрешает ровно одно замыкание для пары коммитов. Для обхода этого ограничения доступна опция --allow-multiple-closures.
После исполнения команды гит сам вычислит изменения, и в конечном коммите станет виден двойной diff: из базовой и замыкающей ветвей. В общем случае это n-мерный diff, то есть выполнять замыкание можно сколько угодно раз. closure-commit похож на merge-commit с той разницей, что в нем хранится несколько сообщений, а не одно.
К сожалению, существующие GUI для работы с Git пока что до конца не поддерживают замыкания. Превью-версия GitExtensions строит кривые как у слияния вместо красивой дуги. Обратите внимание на новые поля Closure message и Closure diff:
Стоит отметить, что команда closure всегда изменяет историю (еще бы, теперь Git — полноценная машина времени!), поэтому пушить ветки теперь можно только с опцией --force, либо с помощью безопасной --force-with-lease.
Рибейзы для ветвей с петлями также доступны, правда, логика пересчета коммитов в них сложна.
Также опция auto позволяет автоматически замыкать все старые ветви. В этом случае замыкающий коммит тот, от которого пошло разветвление. С помощью плагинов к Git IDE замыкания можно запускать периодически. В GitExtensions аналогичный плагин Delete obsolete branches удаляет устаревшие ветви.
Мнение IT компаний
Крупные IT компании: Google, Facebook, Apple, DeepMind, Positive Technologies, а особенно Microsoft, с нетерпением ожидают замыканий, ведь теперь можно будет формализировать жизненный цикл ветвей, в том числе несмерженных.
Один из топ-менеджеров Microsoft, Михаэль Рихтер, пишет:
Новая возможность гита, безусловно, уменьшит хаос в мире Open Source разработки и не только. В наших репозиториях очень много "висящих" ветвей. Например, в vscode их более 200, а в TypeScript их вообще более 300! И это проблема не только Microsoft. Замыкания не только улучшают организацию, но и позволяют отслеживать рассуждения программиста, порой совсем непонятные даже коллегам :) Замыкания напомнили мне фильм "Back to the Future" — там герои путешествовали в прошлое и будущее. Я люблю этот фильм, несколько раз его пересматривал. И думаю, что полюблю гит из-за этого еще больше :)
На заметку
Если раньше граф коммитов представлял из себя направленный ациклический граф (DAG), то замыкания расширяют его до обобщенного ориентированного графа. С помощью Git можно будет описывать регулярные выражения, в которых состояниями будут коммиты, а алфавитом — множество всех сообщений. Но это попахивает хабом "ненормальное программирование", а потому выходит за рамки статьи. Однако если вам такое интересно, то ознакомьтесь со статьей, описывающей, как можно хранить генеалогические деревья внутри Git.
Комментарии (80)
ctacka
01.04.2019 03:21+1А ведь кто-нибудь через пару месяцев наткнется на эту статью и попробует замкнуть
Duduka
01.04.2019 04:20+1А если разработчики гита оценят шутку и замкнут? Вместо дерева — циклические графы, весело! Вы не понимаете, какое же это эстетическое удовольствие создавать новые топологически-художественные коммиты, это же новое веяние в интеллектуальном развитии нейросетей, гит-история начнет самообучаться и после само-рефлексии начнется цивилизация гита.
ctacka
01.04.2019 12:55Надеюсь, что в таком случае естественный отбор уничтожит этого закольцованного уродца в зародыше, он же будет нежизнеспособен.
fshp
01.04.2019 13:25+1Гит это и так граф, а не дерево. В дереве были бы невозможны мержи. Правда граф ациклический.
Mingun
01.04.2019 18:29А затем их поработят иллитиды, а затем они разобъются на гитзераев и гитиянки, а затем придет Зертимон и Git, затем Дак'кон, Безымянный, Неразрывный Круг Зертимона, опять Безымянный, Трансцендентный, Война Крови, священная война, холивар, холивар, холивар...
mwambanatanga
01.04.2019 04:05А как потом удалить замкнутую ветку, если у неё нет головы? Сквошить все коммиты между точкой от почкования и точкой слияния?
Amikko
01.04.2019 04:501 апреля, кто-то читает теги
Вот с какой целью вы добавляете это в теги? (и ещё несколько публикаций грешат тем же)
Розыгрыш не должен быть подписан «это розыгрыш».
mwambanatanga
01.04.2019 06:03Дык розыгрыши нынче настолько основательные, что даже люди [считающие себя] «в теме» верят им. Поэтому, во избежание обвинений в распространении фейк-ньюс, где-нибудь в тексте должен быть намёк на розыгрыш.
Mingun
01.04.2019 19:39Да ладно вам, с первых же слов этой статьи понятно, что к чему :)? Серьёзно, кто-то на это повёлся?
kilgur
01.04.2019 09:10+1Поддержу. Мне кажется, что лучше 2 апреля расставить соответствующие тэги на соответствующие статьи, чем портить эффект розыгрыша.
dimmount
01.04.2019 17:21Без подписи «розыгрыш» вы попадаете под статью о фейковых новостях))). Тем более в эру копипаста розыгрыш на хабре или stackoverflow может причинить серьезный урон инфраструктуре
Atterratio
01.04.2019 11:53+1Ненавижу 1 апреля я тупые около IT шутки в этот день. Имею возможность на работе читать статьи и т.д. по инструментарию, читаю в статью вообще не понимаю что это, зачем и как это решает проблему обозначенную в начале. А голова болит прямо сутра, думаю просто я ничего не понимаю. Пытаюсь из комментов понять, хорошо хоть там относительно сверху написано что это «шутка».
gangstarcj
01.04.2019 12:33Тоже не люблю такое. Это сми же, какие нафиг шутки. Давайте в новостях шутить что началась 3 мировая и на нас летит ядерная ракета. Гы-гы же.
Ivan700
01.04.2019 12:14-320-25 лет назад проект писался максимум тремя программистами на языках для мальчиков и был вылизан до блеска, всё что нужно было — архивирование версий перед крупными доработками, больше для сохранности. Теперь по три сотни программистов пишут свои кривые косяки, используя кривые же библиотеки, путаясь в версиях не только собственных ляпов, но и в версиях багов и «особенностей» библиотек. В итоге на выходе имеем совершенно тривиальные задачи, решённые всё более нетривиальными способами со всё убывающей нагрузочной способностью, релизы софта, год от года становящиеся всё более глючными, обрастающими ненужным функционалом с катастрофически убывающей юзабилити.
И вместо трёх программистов теперь 350 вынужденных инвалидов, решающих больше проблему состоятельности методов решения проблемы, нежели саму проблему.
Я знал, что доживу до времен, когда как программист стану более не нужен на рынке, не знал только, что времена эти наступят при моей еще жизни.
PsyHaSTe
01.04.2019 12:26+1Да-да,
archive_prod3_release_copy (5)_fix27.rarэто верх совершенства, а гит ненужная помойка.Ivan700
01.04.2019 12:39Результат всё равно один.
PsyHaSTe
01.04.2019 12:50Какой один? Как синхронизировать работу хотя бы 5 разработчиков разумными силами?
Вот есть у меня PR, у меня за 2 дня 1500 строк добавлено, 1000 строк удалено. У 4 разработчиков схожие цифры. Где-то треть изменений пересекаются. Как их все объединить, не потеряв работы?Ivan700
01.04.2019 12:56-2Выделяйте в проекте «чёрные ящики». Синхронизируйте работу только на уровне стыковки чёрных ящиков, протоколы взаимодействия должны быть выдолблены перфоратором на стене офиса. На каждом этапе модификаций один человек работает с одним чёрным ящиком. Причем этап это не 3 часа «эффективно сменеждеренного» времени, а минимум пара дней. Спешка хороша только при долбёжке чужой жены в доме её мужа.
PsyHaSTe
01.04.2019 13:15А, ну то есть самостоятельно внедрять басфактор в проект. Ушел человек, который писал модуль Х, и никто не знает, как его чинить и что в нем менять.
Или, например, нужно за неделю сделать несколько фич, и один человек никак не успевает. На тех местах где я работал задачи было принято параллелить, даже если они частично пересекаются. Что предлагаете делать в вашем случае?Ivan700
01.04.2019 14:12В крайнем случае, вы рискуете переписанием ОДНОГО модуля.
Если разбиение достаточно грамотное, то один модуль содержит вполне линейный код, который проанализировать новому человеку не займёт много времени.
А вот рвать время в клочья — это же гарантированный ахтунг с косяками, и гит или любой другой механизм контроля версий — тут просто выполняет роль подтирки на почти гарантированный случай при попытке надрать время — случай, когда все обо… ались и виноватыми будут назначены исполнители, которые, да, начнут уходить…
Ну, к слову, линейность кода — показатель хорошо продуманной системы данных и модулей с субмодулями. А вот многоэтажные логические конструкции — показатель строго противоположного. Я запрещал раньше своим студентам и коллегам использовать табуляцию меньше 8 символов, логика простая: если твой код не влазит на экран по ширине — ты лошара.PsyHaSTe
01.04.2019 14:53В крайнем случае, вы рискуете переписанием ОДНОГО модуля.
Если разбиение достаточно грамотное, то один модуль содержит вполне линейный код, который проанализировать новому человеку не займёт много времени.Я правильно понимаю, что предлагается переписывать модуль каждый раз, как уходит человек его разработавший?
Ivan700
01.04.2019 15:00Зачем?? Если в модуле не так много процедур и они все линейные и написаны читаемо, то в этом нет смысла.
С другой стороны, строго по Генри Форду — какой смысл в проекте, из которого непрерывно бегут люди? Для кого этот проект тогда? Кому он греет карман и душу, кроме владельца проекта? — Раз работникам он неинтересен, то и клиенты получают значит УГ очередное. Это так, бизнес на розах 7го марта, пустышка ценою в маркетинг пустышки.PsyHaSTe
01.04.2019 16:16+1У меня все явственнее видится ваш проект как программа, которую одни и те же люди пилят на протяжении десятков лет, и которые знают каждый её закоулок. Это, конечно, похвально, но у людей разные требования.
С другой стороны, строго по Генри Форду — какой смысл в проекте, из которого непрерывно бегут люди?
Из проекта не бегут люди, у людей бывают разные мотивы. Например, полгода назад у нас ушел девопс, только потому, что ему хотелось больше командировок в страны ближнего и дальнего востока. К продукту не было никаких претензий, просто хотелось путешествовать.
Раз работникам он неинтересен, то и клиенты получают значит УГ очередное.
Мне интересен проект, это не значит, что я не могу уйти на еще более интересный проект. А еще на меня может тупо кирпичь упасть. Я могу поскользнуться и разбить голову. Меня могут ограбить, я могу попасть в ДТП. Куча способов выпасть из разработки.
— Ладно, возьмем менее радикальные варианты. Заболеть человек может? Ну вот просто заболел, и не может свой модуль писать. А модуль очень нужно сделать в течение недели. Ну, например, представьте, что от этого зависит новогоднее выступление президента. Второго января никому не интересно будет, что вы сделали, 31 декабря несъезжаемый дедлайн. Как быть, если никто в команде не понимает, что в этом модуле происходит. Да даже не модуле, а подсистеме. Ведь «20-25 лет назад проект писался максимум тремя программистами», то есть выпавший программист не один модуль за собой тянет, а треть всех модулей в проекте. Предлагаете за неделю во всем разобраться или переписать треть проекта?Ivan700
01.04.2019 17:03Есть некоторая культура кодирования. Если её нет — её надо вводить. В конце концов, нет никакого оправдания для имён переменных вроде POwnRsLockCm. Нет никакого оправдания конструкциям
if()
if()
else if()
else
else
if()
if()
else if()
if()
else
else
else
/// Ну, вы поняли ))
Нет никакого оправдания вариантам вроде
A(){
}
B(){
…
A()
…
}
…
…
…
Z(){
…
Y();
…
}
Как нет и никакого оправдания называть итератор сложнее чем i.
Нет никакого оправдания разбивать проект на 200 файлов, если он вполне логично вписывается в 20, включая файлы визуальной настройки среды разработки.
Нет никакого повода подключать какой-бы-то ни было движок СУБД, если все ваши данные можно свести в 5 несчастных таблиц, в каждой несчастные 200 миллионов записей.
Есть тупо культура, и культурно написанный код всегда читается другим/новым/забывшим специалистом.
Мы ведь все забывшие специалисты — участок, который отлажен и пашет годами — он тупо забывается.
Более того, культурно написанный код более открыт для поиска ошибок, а потому реже их содержит — они видны уже самому разработчику еще до этапа тестирования.PsyHaSTe
01.04.2019 17:07Отлично, согласен со всем написанным.
Непонятно только, как он отвечает на заданные вопросы.
Ivan700
01.04.2019 20:01Это к тому, что может и заболеть, и забеременеть, и уехать в Канаду. В нормальном случае не нужен другой человек, который в курсе заведомо, что делал ушедший, если у ушедшего было достаточно времени, что бы без нервотрёпки писать и доводить до ума красивый, аккуратный и компактный код, где вся сложная математика задокументирована, а всё остальное написано прозрачно и понятно даже человеку с невысокой квалификацией.
PsyHaSTe
01.04.2019 20:48+1Это к тому, что может и заболеть, и забеременеть, и уехать в Канаду.
Верно
В нормальном случае не нужен другой человек, который в курсе заведомо, что делал ушедший
Вывод диаметрально противоположенный правильному.
если у ушедшего было достаточно времени, что бы без нервотрёпки писать и доводить до ума красивый, аккуратный и компактный код, где вся сложная математика задокументирована, а всё остальное написано прозрачно и понятно даже человеку с невысокой квалификацией.
1. аккуратная документация может быть только у продукта, который настоялся хотя бы несколько лет. Документировать когда апи кардинально меняется каждый год не очень получится
2. задокументировать так, что не придется понимать код затруднительно. Возьмите исходный код rustc, там все задокументировано выше некуда, и попробуйте что-нибудь понять.
3. Достаточно времени это сколько? Человек который болеет не будет ничего объяснять, он в очереди в поликлинике сидит или постельный режим соблюдает, человек который увольняется будет в компании 2 недели, за которые трудно объяснить все, человек который помер вообще вряд ли что-то объяснит.Ivan700
01.04.2019 21:01-5rustc…
После этого даже желание как-то реагировать отпадает. )))
Вот ответьте на простой вопрос:
50 лет назад были узкоплатформные ассемблеры.
35 лет назад был кроссплатформный С, потом плюсы.
20 лет назад была совсем платформо-независимая ява и такой же SQL.
Какого дьявола понадобилась вся вот эта остальная языко-платформо-помойка из всяких решеток, питонов, и прочей холеры с дотнетами, которую мы развели себе на голову и теперь георически с ней боремся?..
Сколько проблем вся эта мусорка создала по сравнению с тем, сколько решила?
Ну вот правда, куда теперь без Git? ))))))
Вместо стандартизации и унификации мы теперь идем на поводу у маргинальных диктатур экспресс-решенчества.
Логшика какая была в свое время?
Мало спецов, они дорогие, давайте сделаем средства разработки для лохов.
Сегодня спецов много, но решают они лоховские задачи лоховскими средствами за лоховские деньги.
Доигрались?
Вот медики молодцы, блюдут корпоративный ценз еще со времен Гиппократа :)
0xd34df00d
02.04.2019 01:41С, потом плюсы… А вот вы знаете, что новые стандарты плюсов выходят? Ну там, 11, 14, 17, на подходе 20 вот. Это всё тоже нинужно?
Ivan700
02.04.2019 09:56Нужно, я всегда за стандартизацию и многое давно назрело.
Эволюция С, что мне в нем нравится, очень консервативна, в С не тянут слепо любую появляющуюся тенденцию. Есть правда и некоторые спорные вещи, например за появление template я бы поубивал, столько косяков напложено с применением шаблонных типов. Слава богу эта лихорадка остыла немного. А вот реализация объектного подхода в С(++) изумительная и синтаксически внятная.0xd34df00d
03.04.2019 18:21Есть правда и некоторые спорные вещи, например за появление template я бы поубивал, столько косяков напложено с применением шаблонных типов
Каких?
Не, я не спорю, что кое-что лучше делается через метаклассы, constexpr и тому подобное, но их завезли только относительно недавно.
Ivan700
02.04.2019 10:58И всё же я сторонник жесткой типизации. И противник неявного накладного кода. Одно с другим прямо связано. Причем сегодня это не аппаратная проблема, а культурная. За слово auto отбивал бы руки и мозги.
0xd34df00d
03.04.2019 18:21И всё же я сторонник жесткой типизации.
C++ весьма далёк от жёсткой типизации.
За слово auto отбивал бы руки и мозги.
Чем автоматический локальный вывод типов плох?
0xd34df00d
02.04.2019 01:38На самом деле есть вопросы к самому PR на 2500 измененных строк.
PsyHaSTe
02.04.2019 11:51Поменялось апи (мутабельная структура на иммутабельную), отсюда много изменений в рамках её использования. Вот уже пара сотен строк (в тестах, в основном). Ну и по-мелочи.
PR на 1500 измененных строк, к слову, потому что 1 измененная строка дает 1 удаление и 1 добавление.
mihaild
01.04.2019 12:27>Я знал, что доживу до времен, когда как программист стану более не нужен на рынке, не знал только, что времена эти наступят при моей еще жизни
Вы не знали, что времена, до которых вы доживете, наступят при вашей жизни?Ivan700
01.04.2019 12:38))) Нда, вот так бывает, когда правишь предложение по три раза )) С кодом аналогично — надёжнее переписать ))
Так это и происходит… Сперва утверждается что «переписывать неделю — дорого», а потом оказывается, что наложенная за 5 минут заплатка тянет за собой убытки ещё годами. При этом на времязатраты кодирования накладываются еще бОльшие времязатраты на менеджмент. О нервах вообще молчу.
Через какое-то время из проекта расползаются ключевые фигуры и спустя 10 лет проект становится громоздким возом заплаток, который лечить уже никто не собирается ни за какие деньги — проще начать новый проект.PsyHaSTe
01.04.2019 12:51Гит никак не мотивирует писать или не писать заплатки.
Ivan700
01.04.2019 13:04Ничего не имею против гита самого по себе. Просто он относится к разряду инструментов, которые могут отвлечь внимание от основной цели, если эта цель, разумеется, создание качественного, а не маркетингового продукта.
Есть вещи, которые позволяют ослабить проектную составляющую. А проект это в первую очередь именно проект — цельная концепция, в которую любая рюшечка вписывается сама собой логично.
Когда настает момент, что новая рющечка не вписывается — необходимо перепроектирование, иначе и эта, и все последующие рюшечки автоматически становятся заплатками.PsyHaSTe
01.04.2019 13:18Рюшечка вполне может вписываться, просто разные рюшечки требуют развития в разных направлениях. Например если есть фича добавить логгирование + Любая другая фича, они пересекутся, потому что один человек будет менять функции X, Y, Z, а другой будет добавлять в эти же функции это логгирование. В гите неизбежно будет конфликт, который при условии их простоты (например, описанный случай под такое попадает) будет автоматически разрешен. В случае с файлами мне видится решением разве что использование сторонних тулзов для сравнения директорий чтобы сделать то же самое в полуавтоматическом режиме. Зачем себе усложнять жизнь, непонятно.
Или возьмем более интересный момент. У гита есть куча интересных инструментов, например git bisect. Вопрос — как его эмулировать? Или «нинужна»?Ivan700
01.04.2019 13:36А это потому что у вас не вынесено отдельного чёрного ящика, который идентичен для Х, У и Z. Тогда ведение протокола («логгирование») добавляется девочкой, которая правит черный ящик стандартных процедур/объектов/янии7у для контекстов X, Y и Z, а сами контекстные правки спокойно делаются другой девочкой.
PsyHaSTe
01.04.2019 13:42Погодите, вот у нас есть
void X() { Foo(1, 2) }
Вот девочка добавляет логгирование
void X() { log!("Before Foo"); Foo(1, 2) log!("After Foo"); }
Вот мальчик в это время у себя реализует бизнес-требование передавать айди текущего пользователя в функцию:
void X() { Foo(1, 2, CurrentUserId) }
Какого рода черные ящики тут должны существовать? Как эти изменения дружить друг с другом?
Ivan700
01.04.2019 13:51-1Пример решения вашей проблемы:
class SomeLogTypeClass {
private:
baseClassForXYZ *context;
public:
void __cdecl SomeLogTypeClass L(baseClassForXYZ *c){
context=c;
…
}
…
void __cdecl Log(int m){
… context.UserId…
}
};
…
void __cdecl XClass::X(){
SomeLogTypeClass Log(this);
…
Log.Log(a);
…
Log.Log(b);
…
}
Как вариант, без претензий на вашу конкретику, мне она неизвестна.
И прошу пощения за инлайн, тут неудобно набирать код.
Суть в том, что бы сделать любой субмодуль проекта максимально автономным, насколько это позволяет требование многопоточности, если таковая используется.
В данном случае, перфоратором долбится только то, что в базовом классе есть UserId.
Можно даже сразу прописать в конструкторе базового класса UserId=0, что бы принимать это как знак нештатной ситуации, когда величина останется непрописанной.PsyHaSTe
01.04.2019 14:56У вас очень много деталей, за которыми леса не видно. Можно без плюсов и вот этого всего? Мы не выдумываем иерархию, в которой эта задача решалась бы без изменений (мы ведь не пророки, да?), Мы смотрим ситуацию, когда один и тот же метод должны поправить два человека, причем их задачи никак не связаны — один человек реализует бизнес-логику, другой — инфраструктурную задачу.
Желательно использовать псевдокод как я привел выше, а не писать на плюсах.
Ivan700
01.04.2019 16:49Понимаю, что часто усложнение и/или избыточное дробление к добру не ведут. Тогда разнесите задачи во времени. Сегодня петя вылизывает свою часть и оставляет старый метод для сохранения функциональности старого кода,
завтра маша вносит свои правки по логике, послезавтра Федя спокойно переводит всё на новый код.
В таком варианте вы можете спокойно подвергнуть каждый этап качественному тестированию и оценить все риски.PsyHaSTe
01.04.2019 17:05+1- Во-первых не всегда заранее очевидно, что нужно менять для задачи. Например, оценили, что нужно поменять модуль Х, а во время реализации оказалось, что там были неочевидные завязки на Y и Z, которые в это время правил другой разработчик.
- Во-вторых это просто издевательство над пользователями. "Да, мы знаем, что вы все хотите фичу Х, но у нас Ксюша делает логгирование, поэтому мы не можем её сделать. Зато смотрите, теперь мы поддерживаем новую файловую систему! (разработчику нефиг было делать и он сварганил что-то из низа беклога, что не пересекается по текущим задачам).
- В-третьих при количестве разработчиков за десяток количество комбинаций растет настолько, что в голове удержать что сейчас делать можно, а что нельзя нереально.
- В-четвертых косячить люди все равно будут, потому что они люди собственно.
Подытожим, метод с архивами работает на командах, где люди 20-30 лет сидят на одном проекте, никогда с него не уходят, четко делят границы ответственности по всем модулям, никогда не болеют и не ошибаются.
И до сих пор непонятно, что с гитом не так, ведь с гитом будет все ровно точно так же :) Гит ведь строго мощнее варианта с архивами. Еще и место экономит, потому что дельта-кодирует все.
Ivan700
01.04.2019 20:23-2Ну, так же, по пунктам.
1. Ситуация абсолютно идиотская. Обычно такая ситуация следствие полного отсутствия стадии проектирования, либо следствие безалаберного проектирования, либо отсутствие реализационного видения структуры проекта в виду избытка образования в знаменателе с недостатком опыта независимой разработки в числителе, либо ошибочного видения из-за приверженности некой однобокой парадигме от какого-нибудь забулдыжного коучера, или как их там…
2. Над пользователем не нужно издеваться, заказчик всегда прав, Надо работать вместе с заказчиком, вникать в причину его проблем, а не слепо реализовывать глупости, которые он придумывает, что бы компенсировать глупости разработчика.
Часто слеп и разработчик и заказчик, Только совместные усилия позволяют увидеть правильное продуктовое решение.
Да, бывает, что время не терпит, но потом оно появляется и его надо использовать что бы убирать наставленные впопыхах костыли.
3. Да, Форточки с фортокопродуктами были созданы с вовлечением иногда тысяч индусов. И никакой менеджмент и никакие инструменты не смогли сделать с этим что-либо. Из окон до сих пор торчат тысячи костылей, которые торчали еще в 1994м. Сейчас в той же стадии развития находятся линуксы во всём своём ассортименте. И, несмотря на то, что минули десятилетия, поменялись инструменты, создано еще 40 ненужных языков, ситуация не меняется — то же количество костылей, просто костыли своеобразные.
4. Тем не менее, количество косяков обратно пропорционально качеству и детальности проработки концепта. Как и качество косяков — самые надежные и нелечимые источники косяков заложены в самом концепте.
— Всё с гит-ом так. Только 20 лет назад ты садился и за неделю писал микросервер или CGI, которые волокли на паршивеньком мэйнфрейме столько запросов, сколько мог пропустить к тебе канал. И тебе не нужно было 20 косоруких инвалидов. Хватало одной девочки, которая умеет ровно резать сыр и наливать коньяк. И ничего практически не глючило. И, поэтому, не нужен был гит. :)
А теперь, блин, нужен!!! :)PsyHaSTe
01.04.2019 20:56+2- То есть по-вашему на этапе планирования всегда можно точно оценить список файлов, которые будут затронуты при реализации задачи?
а не слепо реализовывать глупости, которые он придумывает
Приходит такой юзер "вот у вас график по заявкам в разрезе периодов, а нам бы наоборот, по периодам в разрезе заявок", а вы ему такой "что за глупости ты тут мне несешь. Не нужно тебе оно".
Вот так вот махом все продукты созданные более чем парой людей стали нинужным индусософтом? Понятно-понятно.
Видел я софт написанный 20 лет назад, goto на goto и goto погоняет. Звали меня как-то в один бодишоп проект на делфи и .net 1.1 писать. нет, там не было тысяч индусов, всего пара разработчиков. Если аргумент "ну нормальные люди так не писали", попробуйте личным примером показать. Возьмем какую-нибудь несложную софтину, может даже тестовое задание какое-нибудь, и покажете как без этих новомодных плохих технологий все круто и быстро работает.
Ivan700
01.04.2019 21:51-1goto в структурных языках — моветон,
это чуваки явно пересели с бейсика на паскаль )).
Вообще ветвления — это моветон, много ветвлений говорит о непродуманности структур данных.
Ну давайте для примера софтину.
Могу дать код, который долбит по таблице (или паре таблиц, уж не точно помню) отчёт в формате HTML объемом 2-3Гб за пару-тройку секунд на паршивеньком нотбуке. Этот же код забирает данные в таблицу из диспетчерской в текстовом формате.
Там правда была всего неделя на разработку, из которой я 5 дней пил с заказчиком самогон.
Есть и замысловатая математика, но вам это будет скорее всего неинтересно.mkovalevskyi
01.04.2019 22:13+1так вот в чем ваш секрет… ящик самогона — и никаких гитов не надо. вобще ничего не надо. все равно бюджет уже кончился )
mkovalevskyi
01.04.2019 21:33В 1994-м, в форточках были тысячи индусов? Внезапно…
Ivan700
01.04.2019 21:59-1Нет, тысячи им понадобились позже. В 94м там всё еще было относительно хорошо, кроме слюней зависти к Apple и Sun systems, но не было OLE и DDE и кучи других вещей «самих в себе».
А потом стало нужно много кода, поклонники всяких Free-BSD орали «где безопасность?», попёрли всякие NT, ну и там уж понеслось…
Ну и в итоге за всю историю родилось всего два годных продукта — Win7 и офис 2003. Остальное восполнили 3rd-party — Adobe, Oracle, 1C… Сам же микрософт в остальном оказался печален — наклепал многоверсий ублюдочных библиотек и довольно слабо проработанную среду разработки, кто писал драйвера под форточки — поймёт.
reci
01.04.2019 19:11-1Я знал, что доживу до времен, когда как программист стану более не нужен на рынке, не знал только, что времена эти наступят при моей еще жизни.
Вы точно программист?Ivan700
01.04.2019 20:42Теперь уже не уверен, раньше был программистом и электронщиком, а теперь пишу только когда кто-то из друзей упирается рогом в невозможность решить малыми средствами сложную задачу. Сажусь, рисую концепт и методично пару дней пилю то на С то на ассемблере, пока не впишу задачу в требуемый ресурс времени. Обычно бесплатно, из любви к искусству. Иногда еще, когда человек понимает, что не может решить задачу путями, которым его учили на физмате — тогда рожаю адекватный задаче алгоритм или протокол. Я могу писать на решетках и на явах, могу писать запросы, писал много и под 1С, но меня это бесит, не моё. Как буд-то кто-то пытался упростить жизнь, создавая эти инструменты, но в итоге усложнил и сделал простое ненужно сложным. Это уже не мой мир, это мир поколения, которое мы учили. Хреново учили, наверное.
elmm
01.04.2019 15:20+3Мне такие шутки напомниают историю как в конце 90х компьютерный журнал пошутил про разблокировку разгона процессора путём его сверления, а следующих номерах публиковали письма недовольных разгонщиков. Осторожнее надо быть.
akdes
01.04.2019 15:55+3я себе сегодня сказал, что я не попадусь на шутки… поздравляю, у Вас получилось.
Я уже было начал писать инструкцию своей тиме о новвоведении в гит…
vyo
01.04.2019 17:10+1Так-то говоря, это просто расширенный мердж. Зачем команду-то вводить новую? Так просто всем инструментам нужно было бы просто повыкидывать кучу проверок на слияемость и заменить на `return true`.
Киньте proposal кто-нибудь что-ли.lunavsegba
01.04.2019 18:12-1Чувак, это шутка, 1 апреля
vyo
01.04.2019 18:32+1Я это понял ещё до того, как писать комментарий выше. Почему бы не поддержать хорошую шутку :)?
P.S.: про первое апреля я уже часов 12 как знаю из-за StackOverflow.
crea7or
Какую проблему это решает? То, что висят ветки и их не хочется удалять?
Reey
Часто бывает когда коммит ломает обратную совместимость в минорной ветке, ну и тут либо git revert на несколько коммитов, либо git reset.
Mingun
И чем в этом случае поможет новая команда?
bogolt
Через незамкнутые ветки из репозитория вытекает энергия!