Выпуск системы управления исходными текстами Git 2.44

24.02.2024 12:56

После трёх месяцев разработки опубликован выпуск распределенной системы управления исходными текстами Git 2.44. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. Код Git распространяется под лицензией GPLv2+.

По сравнению с прошлым выпуском в новую версию принято 503 изменения, подготовленных при участии 85 разработчиков, из которых 34 впервые приняли участие в разработке. Основные новшества:

Добавлена новая команда "git replay", которая может применяться в качестве альтернативы "git rebase" и использоваться для воссоздания истории на сервере без рабочего дерева (bare-репозиторий, не содержащий рабочего дерева), обработки одновременно нескольких веток, выполнения операции rebase для веток, отличных от извлечённых в данный момент, или просто для ускорения операций слияния.
Добавлена поддержка системы непрерывной интеграции GitLab CI.
В команды "git add" и "git stash" добавлена поддержка атрибутов путей ":(attr:...)", задаваемых по аналогией с командой "git show". Например "git add ':(attr:~binary)'" можно использовать для добавления всех текстовых (не бинарных) файлов в индекс. Дополнительно в новом выпуске предложен атрибут "builtin_objectmode" для фильтрации файловых путей по правам доступа. Например, "git add ':(attr:builtin_objectmode=100755)'" можно использовать для добавления всех исполняемых файлов.
Добавлена поддержка повторного использования объектов, распределённых по нескольким pack-файлам, для которых присутствует сводный индекс (multi-pack-index) с данными о доступности объектов (оптимизация, позволяющая вместо фактической передачи данных, сослаться на использование данных, уже присутствующих в pack-файлах). Начиная с версии 2.44 git при теперь может обрабатывать повторное использование объектов поверх нескольких pack-файлов, без необходимости переупаковки репозитория в один pack-файл. Для включения новой возможности следует выполнить команды:
```
   git config --global pack.allowPackReuse multi
   git multi-pack-index write --bitmap
```
после чего число pack-файлов, из которых повторно используются объекты, можно отследить в значении "pack-reused ... (from N)", показываемом при выполнении "git push".
Команда "git rebase --autosquash" теперь может применяться для операций rebase в неинтерактивном режиме, что позволяет выполнить rebase и быстро применить fixup-исправления без инспектирования списка изменений и не меняя переменную окружения GIT_SEQUENCE_EDITOR.
В команду "git merge-file" добавлена опция "--diff-algorithm" для выбора альтернативного алгоритма оценки различий между файлами.
В команде "git checkout -B <branch> [<start-point>]" запрещено обновление и извлечение веток, использующих другое рабочее дерево. Для возвращения старого поведения добавлена опция "--ignore-other-worktrees".
Добавлена возможность присвоения настройке "git config advice.pushAlreadyExists" значения "true", убирающего при выводе подсказок (hint) инструкцию по их отключению ("Disable this message with..."), занимающую место на экране.
Оптимизировано выполнение команды "git for-each-ref" с опцией "--no-sort", которая теперь приводит к выводу в неопределённом порядке (ранее при указании "--no-sort" всё равно применялась сортировка по алфавиту). После внесения оптимизаций применение "--no-sort" теперь ускоряет "git for-each-ref" примерно на 20% в репозиториях с большим числом ссылок.
В бэкенд управления учётными данными wincred добавлена поддержка обновления токенов OAuth, по аналогии тем как это реализовано в бэкендах credential-cache и credential-libsecret.
В "git fetch" добавлена поддержка параметра конфигурации "fetch.all", который будет обработан по аналогии с добавлением опции "--all" в командной строке.

исправить +19 +/–

Лицензия: CC BY 3.0

Короткая ссылка: https://opennet.ru/60659-git

Ключевые слова: git

При перепечатке указание ссылки на opennet.ru обязательно

Обсуждение (85)

1.1, Аноним (1), 13:24, 24/02/2024 [ответить] [﹢﹢﹢] [ · · · ]	+24 +/–
Гит пора заносить в Парижскую палату мер и весов в категории "когда коту делать нечего". Такого награмождения фич, нужных 0,3 анониму нету нигде. Гит сожрёт сам себя.

2.5, Аноним (5), 13:48, 24/02/2024 [^] [^^] [^^^] [ответить]	–3 +/–
Ну почему развитие продукта идет исключительно по пути дальнейшего "награмождения фич"? Почему отсутствуют новости типа: - оптимизирована работа с памятью; - добавлена поддержка аппаратных инструкций; - критичные функции переписаны на asm/rust; - произведена чистка кодовой базы; и т.п.?

3.7, Аноним (7), 13:51, 24/02/2024 [^] [^^] [^^^] [ответить]	+1 +/–
Потому что проект не стагнирует, а перечисленное тобой верный симптом умирания.

4.17, Аноним (5), 14:28, 24/02/2024 [^] [^^] [^^^] [ответить]	+8 +/–
Перечисленное мной - симптомы зрелости (production ready). А ты, похоже, путаешь "не стагнирует" с подростковым энтузиазмом.

5.19, Аноним (7), 14:48, 24/02/2024 [^] [^^] [^^^] [ответить]	+/–
Ты подменяешь понятия. Мамонтовость и окаменелость не является зрелостью, и уж тем более они не являются пригодностью к применению в коммерческих продуктах. Сегодня продакшен-реди это когда развитие не прекращается и проект сохраняет актуальность, по возможности избегая слишком кардинальных изменений. В случае с гитом же, виден общий вектор развития, нацеленный на применение в практической разработке, там, где исходники на сотни и тысячи гигабайт.

6.24, Аноним (24), 15:35, 24/02/2024 [^] [^^] [^^^] [ответить]

–1 +/–

>продакшен-реди это когда развитие не прекращается и проект сохраняет актуальность

Как, например, в ядре вносят порчу фс или в систем-д - затирание биоса? Сохраняет актуальность, что и не говори.

>исходники на сотни и тысячи гигабайт

Модульность и стабильность АПИ между компонентами Н.Е_Н.У.Ж.Н.О?

6.39, Аноним (5), 18:47, 24/02/2024 [^] [^^] [^^^] [ответить]

+2 +/–

> оптимизирована работа с памятью;
> добавлена поддержка аппаратных инструкций;
> критичные функции переписаны на asm/rust;
> произведена чистка кодовой базы;

Это ты ВОТ ЭТО называешь "Мамонтовость и окаменелость"?

Поколение Айфона...

7.40, Аноним (7), 18:53, 24/02/2024 [^] [^^] [^^^] [ответить]	–2 +/–
Это глупости, в нормальном проекте подобное где-то в самом конце списка приоритетов. Если будет актуально, будет применено вместе с реальными улучшениями.

8.81, Аноним (81), 01:04, 26/02/2024 [^] [^^] [^^^] [ответить]	+/–
Вот вам и ответ, почему так упало качество ПО ... текст свёрнут, показать

9.93, Аноним (7), 08:53, 26/02/2024 [^] [^^] [^^^] [ответить]	+/–
ПО никогда не было качественным, что ты фантазируешь Относительно чего оно могл... текст свёрнут, показать

10.105, Аноним (105), 22:31, 27/02/2024 [^] [^^] [^^^] [ответить]	+/–
Мелкомягкое ПО редко когда было качественным Но сейчас стало ещё хуже Качество... текст свёрнут, показать

5.26, Аноним (26), 16:00, 24/02/2024 [^] [^^] [^^^] [ответить]	+2 +/–
>production ready Ничего более production ready, чем Git, которым пользуется почти весь прод и представить нельзя. То что там добавили пару новых фич, не ломая старых - не имеет значения. 99% не заметят разницы.

6.44, Аноним (5), 19:20, 24/02/2024 [^] [^^] [^^^] [ответить]	+1 +/–
>пользуется почти весь прод Угадай с трех раз, почему реальный прод (RHEL, Ubuntu etc) до сих пор использует версии git 2.25

7.85, Аноним (-), 05:46, 26/02/2024 [^] [^^] [^^^] [ответить]

+/–

>>пользуется почти весь прод
> Угадай с трех раз, почему реальный прод (RHEL, Ubuntu etc) до сих
> пор использует версии git 2.25

Наверное, потому что никто не кодит софт на серваках, например :P.

7.94, Аноним (94), 13:49, 26/02/2024 [^] [^^] [^^^] [ответить]

+/–

> Угадай с трех раз, почему реальный прод (RHEL, Ubuntu etc) до сих пор использует версии git 2.25

$ git --version
git version 2.34.1

Ubuntu 22.04

RHEL не проверял. Но если и так, то скорее всего потому, что на момент релиза актуальная версия была именно такая.

7.106, Аноним (105), 22:35, 27/02/2024 [^] [^^] [^^^] [ответить]

+/–

> Угадай с трех раз, почему реальный прод (RHEL, Ubuntu etc) до сих пор использует версии git 2.25

Т.к. они используют целиком дистрибутив с комплектным софтом из репо, проверенным на работоспособность. Не занимаются точечным обновлением пакетов, т.к. не рискуют нарваться на баги, для которых неизвестны способы обхода.

А вот когда обновят дистр., то и версии помолодеют.

В проде вообще хорошо, когда поменьше обновлений. Меньше вероятность схлопотать чужую и ненужную недодумку.

5.36, Аноним (36), 17:53, 24/02/2024 [^] [^^] [^^^] [ответить]	+2 +/–
> Перечисленное мной > переписаны на Rust > с подростковым энтузиазмом А завтра ты новый язык выучишь, и опять всё переписывать?

6.65, scriptkiddis (?), 22:36, 24/02/2024 [^] [^^] [^^^] [ответить]	+/–
Есстесственно! И не по одному разу!

3.25, Аноним (25), 15:42, 24/02/2024 [^] [^^] [^^^] [ответить]	+1 +/–
> - добавлена поддержка аппаратных инструкций; > - критичные функции переписаны на asm/rust; Спасибо, не надо.

3.73, Аноним (73), 06:13, 25/02/2024 [^] [^^] [^^^] [ответить]	+1 +/–
>- критичные функции переписаны на asm/rust; Переписать критичную функцию на языке с нестабильным синтаксисом, тянущим тысячу лефтпадов через карго культ в проект. Отличный план. Кто это повторит - не забудьте: минорный релиз должен быть.

3.78, User (??), 14:34, 25/02/2024 [^] [^^] [^^^] [ответить]	+/–
Предполагаю, что развитие _этого_ продукта нужно вот 0,3 анонимам - а все полезное пилится где-то в гитхабе\лабе\IDE...

3.92, Аноним (92), 08:52, 26/02/2024 [^] [^^] [^^^] [ответить]	+/–
> - критичные функции переписаны на asm/rust; А как же безопасная работа с памятью в асме? Тогда уж лучше, чем "- критичные функции переписаны на asm" потому что раст и так написан на C

2.6, Аноним (-), 13:51, 24/02/2024 [^] [^^] [^^^] [ответить]	–1 +/–
Как? Неужеди Git стал сложнее высшей математики?

2.11, Аноним (11), 14:09, 24/02/2024 [^] [^^] [^^^] [ответить]	+/–
> нету нигде. Есть fossil, где помимо вот этого всего всего ещё и вебморда уровня gitea из коробки

2.34, Аноним (34), 17:28, 24/02/2024 [^] [^^] [^^^] [ответить]	–1 +/–
Просто ты совершенно не понимаешь что происходит и какие есть проблемы у git

1.8, Аноним (8), 13:54, 24/02/2024 [ответить] [﹢﹢﹢] [ · · · ]	+6 +/–
Лишь бы на SHA256 не переходить.

2.9, Аноним (9), 13:56, 24/02/2024 [^] [^^] [^^^] [ответить]	–1 +/–
шо?

2.97, Аноним (97), 16:32, 26/02/2024 [^] [^^] [^^^] [ответить]	+/–
Я бы даже предпочёл переход на BLAKE3.

1.10, Аноним (10), 14:07, 24/02/2024 [ответить] [﹢﹢﹢] [ · · · ]	–2 +/–
Система управления, да ещё "исходными текстами" это новость про картотеку?

1.15, Аноним (15), 14:21, 24/02/2024 [ответить] [﹢﹢﹢] [ · · · ]	–5 +/–
>Добавлена поддержка системы непрерывной интеграции GitLab CI. Ну то есть раньше было гит=гитхаб, а сейчас гит=гитлаб. Кушайте, не обляпайтесь, подсаживайтесь на сервис.

2.18, Аноним (18), 14:36, 24/02/2024 [^] [^^] [^^^] [ответить]	+2 +/–
По ссылочке-то пройди. К исходникам гита добавили yaml-файл для гитлаб-ци, если кому-то зачем-то понадобится собрать гит из исходников при помощи гитлаб-ци.

2.48, Аноним (48), 20:13, 24/02/2024 [^] [^^] [^^^] [ответить]	+4 +/–
Тебе ли не пофиг в чём не разбираться?

1.21, m228chtig (?), 15:12, 24/02/2024 [ответить] [﹢﹢﹢] [ · · · ]	+/–
Я не успеваю изучить и опробовать новые фичи, как вдруг выкатывают новый релиз...

2.23, Аноним (23), 15:30, 24/02/2024 [^] [^^] [^^^] [ответить]	+/–
Старость конечно не радость.

2.31, Аноним (31), 16:33, 24/02/2024 [^] [^^] [^^^] [ответить]	+1 +/–
Главное что основные работают. Зачем все попробовать? Соевый что ли?

2.41, got (?), 18:55, 24/02/2024 [^] [^^] [^^^] [ответить]	+/–
Я недавно нашел fixup/autosquash фичу и удивлялся почему она не работает с неинтерактивным rebase. А тут это как раз исправили, замечательно! А на новые фичи пофиг

1.27, Аноним (27), 16:03, 24/02/2024 [ответить] [﹢﹢﹢] [ · · · ]	+7 +/–
И по-прежнему hg проще и понятнее, а самое главное — системно более строже и логичнее. Что там с rhg? Обещали лютый прирост скорости (ну, после питона-то).

2.49, Аноним (48), 20:18, 24/02/2024 [^] [^^] [^^^] [ответить]	+/–
Если hg запускается 0 раз, то перфоманс увеличивается до бесконечности, учи математику

3.60, Аноним (27), 21:57, 24/02/2024 [^] [^^] [^^^] [ответить]	–1 +/–
Когда интернет-троллинг скатился до такого дна? Почему мегаумы прошлых лет уступили место очкасто-прыщавым в плохом смысле зaдpoтaм, которые шамкая недоразвитой челюстью выдают такой уровень «иронии», достойной разве что веганских пабликов? Как производительность хорошего, но не очень распиаренного продукта кореллирует с его количеством запусков? Ты реально настолько туп, что для тебя это логично и даже смешно? Ты наркоман?

4.90, Витюшка (?), 07:03, 26/02/2024 [^] [^^] [^^^] [ответить]	+/–
Напрямую коррелирует. Почитай кто здесь переписал бэкенд merge и rebase? У кого их миллионы, а может сотни миллионов в день? Ещё раз хорошенько подумай.

2.58, Аноним (58), 21:54, 24/02/2024 [^] [^^] [^^^] [ответить]	+3 +/–
Пайтон тут причем, если упор чисто в io?

3.62, Аноним (27), 22:02, 24/02/2024 [^] [^^] [^^^] [ответить]	+2 +/–
Жаловались, что беда была именно в этом. Я нутро ртути не изучал, заявлять однозначно не могу, но помню что ртуть переписывать брался фейсбук (чем кончилось — хз, может прикопали, а может у себя пользуют), и что rhg вроде как ощутимо быстрее. Вторым пунктом, на который традиционно жалуются смузикодеры с гита — отсутствие из коробки возможности откатить коммит (ребэйс, кажись). Но во-первых её можно было плагином доустановить, а во-вторых она противоречит принципам ртути — что все изменения должны фиксироваться, и если кто-то закоммитил фигню, то должен следом слать исправляющий коммит, дабы журнал всё фиксировал и сохранялась однозначность веток-цепочек.

4.66, Аноним (94), 22:51, 24/02/2024 [^] [^^] [^^^] [ответить]

+/–

> она противоречит принципам ртути

Если принципы инструмента идут вразрез с принципами пользователей, то инструмент идёт нафиг.

Это к вопросу "почему hg менее популярен, чем git."

4.70, Аноним (70), 03:45, 25/02/2024 [^] [^^] [^^^] [ответить]	+/–
Из известных мне трёх случаев намеренного отказа от hg в двух именно это было пр... большой текст свёрнут, показать

5.74, Аноним (27), 10:09, 25/02/2024 [^] [^^] [^^^] [ответить]	–1 +/–
Вечно мутирующая система стандартом быть не может. То, что её безальтернативно продвигают, как и линукс — это другой вопрос.

6.77, Аноним (94), 14:23, 25/02/2024 [^] [^^] [^^^] [ответить]	–1 +/–
Кто продвигает? Не иначе как массоны и всемирный заговор?

7.109, zog (??), 12:37, 28/02/2024 [^] [^^] [^^^] [ответить]	+/–
Масоны пишутся с одной С.

5.98, Аноним (97), 16:39, 26/02/2024 [^] [^^] [^^^] [ответить]

+/–

Очень согласен с основными мыслями поста.

И добавлю, что

> неудаляемые ветки

в Меркуриале таки отсутствуют, как и в Git, как и в SVN, как и в CVS.

6.100, Аноним (100), 21:53, 26/02/2024 [^] [^^] [^^^] [ответить]	+/–
> в Меркуриале таки отсутствуют, как и в Git, как и в SVN, как и в CVS. Ложь. Удалить ветку в Git не проблема.

7.102, Аноним (102), 14:02, 27/02/2024 [^] [^^] [^^^] [ответить]	+/–
Перечитай пост, на который отвечаешь, а то у тебя взаимоисключающие предложения.

4.72, Аноним (73), 05:57, 25/02/2024 [^] [^^] [^^^] [ответить]	+2 +/–
Фатальный недостаток. Хотя, если исправляется плагином - то норм. Понимаешь, бывает что обколюсь и начну коммитить. Сами изменения я сделал ранее, когда был в адеквате, а вот коммит делаю уже намухоморенным. Предохранитель канеш сработал не отправить на сервер, но вот смотрю я историю коммитов, и вижу что пять коммитов назад я писал такую чухню, что не дай господь. Вот как мне переписать коммит сообщение? Не код, с ним все в порядке. Только сообщение.

4.104, минона (?), 19:36, 27/02/2024 [^] [^^] [^^^] [ответить]	+/–
ну и зачем в истории куча мусора, которая нужна была только для того, чтобы фиксировать какие-то промежуточные идеи и состояния

2.68, хрю (?), 00:54, 25/02/2024 [^] [^^] [^^^] [ответить]	+2 +/–
Но hg никто не хочет поддерживать и нет ничего даже отдалённо напоминающего gitlab. И даже в ide всё чаше hg поломанное/глючит. Так выглядит умирание. Хотя фич hg хватит 90% разрабов на 95% проектах.

3.88, Аноним (-), 06:04, 26/02/2024 [^] [^^] [^^^] [ответить]	+1 +/–
Потому что питоняши накидали как обычно - хаотичное месиво, без намека на архите... большой текст свёрнут, показать

1.28, Ананоним (?), 16:08, 24/02/2024 [ответить] [﹢﹢﹢] [ · · · ]	–2 +/–
Когда важный инструмент для процесса разработки ПО постоянно обновляется, это наводит на неприятные мысли о высокой вероятности хлебнуть нешуточных проблем с целостностью хранилища. Для серьёзных ответственных дел такое не годится. Правильно кто-то написал, что давно пора было сделать простой и понятный инструмент, отладить и оптимизировать его до совершенства и больше не выпендриваться.

2.29, Troll (?), 16:27, 24/02/2024 [^] [^^] [^^^] [ответить]	+/–
Кто-то заставляет использовать именно сабж? Просто шлите нахер. А если не заставляют, есть вменяемые альтернативы.

2.30, Аноним (31), 16:29, 24/02/2024 [^] [^^] [^^^] [ответить]	+/–
> Правильно кто-то написал, что давно пора было сделать простой и понятный комментарий, отладить и оптимизировать его до совершенства и больше не выпендриваться. Поправил тебя, не благодари

2.33, penetrator (?), 16:51, 24/02/2024 [^] [^^] [^^^] [ответить]

+/–

раз фичи выходят значит кому-то это нужно

попробуй обобщить весь этот опыт, притом что он не перестает накапливаться и модифицироваться

и второе - самая проблемная часть

2.63, Аноним (27), 22:04, 24/02/2024 [^] [^^] [^^^] [ответить]	+3 +/–
>>Правильно кто-то написал, что давно пора было сделать простой и понятный инструмент, отладить и оптимизировать его до совершенства и больше не выпендриваться. SVN Простите.

3.99, Аноним (97), 16:54, 26/02/2024 [^] [^^] [^^^] [ответить]	+/–
Ага, очень понятный инструмент: * Для развёртывания SVN-сервера почему-то нужна СУБД. * Если нет связи с сервером, например в поездке - ничего не закоммитишь, ветку не сменишь. * Ветка или тэг хранится как каталог файловой системы. То есть пространства каталогов, веток и тэгов не разделены. Как результат, нельзя с уверенностью сказать, то ли это ветка, то ли тэг, то ли просто каталог. * Нет ни нормального мержа, ни ребейса.

2.80, Аноним (80), 23:29, 25/02/2024 [^] [^^] [^^^] [ответить]	+/–
Ваши абстрактные страхи я вполне понимаю - "не дай бог какой-то Васян вкорячит фичу, она-то будет работать, да отвалятся остальные". Но с другой стороны, DVCS - штука довольно сложная и ОБЯЗАНА развиваться. Собственно, для того и существуют "бета" версии - для обката фич. Если сделать инструмент только на базовых фичах версионности, то в первую же неделю использования вы столкнётесь с массой отсутствующих маленьких, но очень приятных фич. Надо пилить новую систему а-ля Hg, но без богомерзкого пестона - этим языком дубина-автор сразу же похоронил проект.

1.37, Аноним (37), 18:12, 24/02/2024 [ответить] [﹢﹢﹢] [ · · · ]	+1 +/–
Совсем недавно узнал про ключ ---depth в git clone. Этож сколько времени и дискового пространства потрачено нами впустую...

2.38, Аноним (38), 18:17, 24/02/2024 [^] [^^] [^^^] [ответить]	+1 +/–
А я вот сразу, когда мне понадобилось качать большую репу, ввел в Гугле "как скачать один коммит" и нашел про depth

2.42, Аноним (7), 19:00, 24/02/2024 [^] [^^] [^^^] [ответить]	+1 +/–
> Совсем недавно узнал про ключ ---depth в git clone. Этож сколько времени > и дискового пространства потрачено нами впустую... Теперь открой для себя --single-branch. Впустую или нет вопрос открытый, иногда надо откатить определённые коммиты, чтобы вообще собралось, или просто удалить неугодные изменения (но это путь вникуда, и не всегда разрабы желают кооперироваться).

1.46, Аноним (46), 20:01, 24/02/2024 [ответить] [﹢﹢﹢] [ · · · ]	+/–
> Добавлена поддержка системы непрерывной интеграции GitLab CI. Что это значит?

2.107, Аноним (105), 22:47, 27/02/2024 [^] [^^] [^^^] [ответить]	+/–
Добавили конфиги для запуска компиляции/сборки Гит внутри сабжа - https://github.com/git/git/commit/0e3b67e2aa25edb7e1a5c999c87b52a7b3a7649a Кмк не та вещь, чтобы упомянуть. В т.ч. т.к. напрямую к Гиту отношения не имеет.

1.50, Аноним (50), 20:19, 24/02/2024 [ответить] [﹢﹢﹢] [ · · · ]	+/–
Какой же это комбайн. Есть что то легковесное типа гита?

2.57, Аноним (58), 21:52, 24/02/2024 [^] [^^] [^^^] [ответить]	+5 +/–
New folder -> Copy. Для 99% домашних проектов хватит, потом через вебморду выгрузишь на гитхаб если надо.

2.64, Аноним (27), 22:07, 24/02/2024 [^] [^^] [^^^] [ответить]	+/–
Fossil, но он неоднозначный. Mercurial в целом можно использовать практически как drop-in замену svn, точно надёжнее гита.

3.86, Аноним (-), 05:49, 26/02/2024 [^] [^^] [^^^] [ответить]	+2 +/–
> Fossil, но он неоднозначный. > Mercurial в целом можно использовать практически как drop-in замену svn, точно надёжнее гита. Drop in замена всякого антиквариата нужна только всяким совсем необучаемым некромансерам, не способным в современные эффективные децентрализованные workflow.

4.91, User (??), 07:41, 26/02/2024 [^] [^^] [^^^] [ответить]	+/–
Самое тут забавное - что индустрия как раз таки вернулась к классическому централизованному workflow с единой "точкой истины" в виде gitlab'a\github'a\bitbucket'а \ с развесистым CI\CD. На чуть более другом техническом уровне, да - но вожжи с колесами прям те же самые.

2.67, Аноним (67), 23:48, 24/02/2024 [^] [^^] [^^^] [ответить]	+/–
got (gameoftrees) есть

2.69, хрю (?), 00:58, 25/02/2024 [^] [^^] [^^^] [ответить]	+/–
hg - понятнее, с гуём из коробки, децентрализованное - вообще самое то для новичков. но интеграция с ide начинает умирать, так же всё плохо с интеграциями в корпоративные порталы совместной разработки.

3.82, Аноним (81), 01:13, 26/02/2024 [^] [^^] [^^^] [ответить]	+/–
У Mercurial очень понятные команды, никогда не ощущал необходимости в GUI.

4.96, Аноним (97), 16:18, 26/02/2024 [^] [^^] [^^^] [ответить]	+/–
Особенно понятно иметь 3 типа веток, несколько голов в одной ветке и 2 типа обозначения коммитов

1.52, Аноним (38), 20:43, 24/02/2024 [ответить] [﹢﹢﹢] [ · · · ]	+/–
Но вот что меня потрясает - это такой комбайн, а ни одного бага, который бы портил данные, в целом не помню на своей практике чтобы гит имел хоть единый баг. Как они только так умело кодить умудряются?

2.83, Аноним (81), 01:15, 26/02/2024 [^] [^^] [^^^] [ответить]	+/–
"Просто пишите нормально" (c) - как раз тот случай когда так и сделали.

3.108, Аноним (105), 22:50, 27/02/2024 [^] [^^] [^^^] [ответить]	+/–
Некоторым код SVN нравился больше. Впрочем, как и UDP код против TCP под Лялих.

1.56, Аноним (58), 21:51, 24/02/2024 [ответить] [﹢﹢﹢] [ · · · ]	+3 +/–
Гит стал сложнее матана. Уже есть вакансии git engineer?

2.61, BrainFucker (ok), 21:57, 24/02/2024 [^] [^^] [^^^] [ответить]	+1 +/–
Кто ж заставляет использовать что-то кроме pull, merge, add, commit и push?

3.75, Аноним (-), 11:33, 25/02/2024 [^] [^^] [^^^] [ответить]	+/–
Всё равно нужна отдельная вакансия про специалисту Git. Зарплата думаю 100 штук в месяц хватит.

4.76, BrainFucker (ok), 11:40, 25/02/2024 [^] [^^] [^^^] [ответить]	+1 +/–
С одной стороны почему бы и нет, зато можно устроиться в условный FAANG и работать левой пяткой, что-то за это получая. С другой стороны в долгосрочной перспективе xз зачем это всё, учитывая развитие машинного обучения. Это всё можо будет автоматизировать и всех поувольнять.

5.79, Анонист (?), 17:28, 25/02/2024 [^] [^^] [^^^] [ответить]	+1 +/–
В моей конторе в прошлом году появился prompt engineer, который составляет промпты для чатжпт. Всех джунов уволили. И что-то подсказывает, это только первые ласточки.

1.59, BrainFucker (ok), 21:55, 24/02/2024 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ] [к модератору]	+/–

игнорирование участников | лог модерирования

Добавить комментарий

Текст: