The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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

18.11.2025 17:28

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

По сравнению с прошлым выпуском в новую версию принято 637 изменений, подготовленных при участии 94 разработчиков (33 впервые приняли участие в разработке Git). Основные новшества (1, 2, 3):

  • Добавлена команда "git last-modified" для отображения списка файлов в указанной ревизии и коммитов, через которые вносились последние изменения в каждый из этих файлов.
    
       $ git last-modified HEAD
    
       b56f6dcd7b4c90192018e848d0810f091d092913        test.h
       29330ae4b820147c98e723399e9438c8bee60a8a        test1.c
       573ad8917beb99dc643b6e7f5c117a294384a575        test2.c
    
  • Добавлена команда "git repo" для выполнения действий, связанных с извлечением информации из репозитория. Предложены две подкоманды - "git repo info" и "git repo structure", выводящие информацию о настройках репозитория и сведения о структуре репозитория (например, можно узнать число ссылок и объектов в репозитории).
    
       $ git repo info object.format references.format
    
       object.format=sha1
       references.format=reftable
    
       $ git repo structure
      
       | Repository structure | Value  |
       | -------------------- | ------ |
       | * References         |        |
       |   * Count            |   1983 |
       |     * Branches       |      4 |
       |     * Tags           |   1125 |
       |     * Remotes        |    854 |
       |     * Others         |      0 |
       |                      |        |
       | * Reachable objects  |        |
       |   * Count            | 518955 |
       |     * Commits        |  77469 |
       |     * Trees          | 188865 |
       |     * Blobs          | 251631 |
       |     * Tags           |    990 |
    
  • В команду "git refs" добавлены три подкоманды, унифицирующие разрозненные и пересекающиеся низкоуровневые операции над ссылками (git for-each-ref, git show-ref, git update-ref и git pack-refs):
    • "git refs optimize" - оптимизация бэкенда хранения ссылок (по аналогии с "git pack-refs").
    • "git refs list" - вывод списка всех ссылок (по аналогии с "git for-each-ref" или "git show-ref").
    • "git refs exists" - проверка существования ссылки (аналог "git show-ref --exists").
  • Формат для экспорта или импорта истории коммитов расширен возможностью работы с криптографическими подписями, использующими как идентификаторы объектов на базе алгоритма SHA-1, так и на основе SHA-256. В команде "git fast-import" реализована поддержка обработки подписанных тегов по аналогии с подписанными коммитами. Добавлены опции "--signed-commits=<режим>" и "--signed-tags=<режим>" для управления обработкой подписанных коммитов и тегов на этапе импорта (режим может принимать значения verbatim, warn-verbatim, warn-stri, strip или abort).
  • В команду "git maintenance" добавлена поддержка новой стратегии "geometric" ("git config set maintenance.strategy geometric"), позволяющей сократить время обслуживания крупных монорепозиториев. По сравнению с ранее доступной стратегией, использующей логику как в команде "git gc", новая стратегия избегает переупаковки всех объектов и исключает излишне ресурсоёмкие операции, такие как слияние всех pack-файлов (по возможности объединение производится частями и без чистки удалённых объектов).
  • Добавлена команда "git sparse-checkout clean" для упрощения восстановления состояния рабочего каталога, путём удаления файлов, не соответствующих новому определению sparse-checkout, которые не должны присутствовать в локальной копии в соответствии с текущими параметрами sparse-checkout.
  • Для избавления кодовой базы от усложнений и упрощения сопровождения проведён рефакторинг для уменьшения использования глобальной переменной the_repository.
  • Расширено применение фильтров Блума, вероятностной структуры для проверки вхождения во множество, допускающей ложное определение отсутствующего элемента, но исключающая пропуск существующего элемента. Фильтры Блума теперь применяются для ускорения поиска в истории изменений при указании масок в файловых путях, например, "foo/bar/*/baz".
  • Производительность команды "git describe" повышена до 30%, благодаря использовании очереди приоритетов. В "git remote rename" ускорены операции переименования ссылок. В "git ls-files" расширено применение индексов. Заметно ускорена работа команды "git log -L", благодаря исключению излишних трёхуровневых сравнений при обработке слияния коммитов. Внесены оптимизации в библиотеку xdiff.
  • Предоставлена опциональная возможность использования реализаций на языке Rust некоторых внутренних функций, таких как кодирование и декодирование целочисленных значений переменной длины. По умолчанию код на Rust не используется и для включения требует указания сборочного флага WITH_RUST. В будущем ожидается переработка на Rust более значительны внутренних компонентов Git и добавление Rust в число обязательных сборочных зависимостей в Git 3.0.
  • Обновлён список нарушающих совместимость изменений, которые будут применены в ветке Git 3.0. В Git 3.0 решено изменить настройку init.defaultBranch по умолчанию в значение "main", т.е. в репозиториях, созданных командой "git init", ветка по умолчанию будет именоваться "main", а не "master". Также отмечается переход по умолчанию на идентификаторы объектов на основе алгоритма хэширования SHA-256 при инициализации новых репозиториев. Для упрощения переносимости между репозиториями с идентификаторами объектов на базе хэшей SHA-1 и SHA-256 предоставлена возможность в репозитории с одним алгоритмом хеширования, выполнять операции push и pull из репозитория, использующего другой алгоритм хеширования.


  1. Главная ссылка к новости (https://lore.kernel.org/lkml/x...)
  2. OpenNews: В Git 3.0 предложено сделать Rust обязательной частью сборочной инфраструктуры
  3. OpenNews: Выпуск системы управления исходными текстами Git 2.51
  4. OpenNews: Уязвимости в Git, допускающие выполнение кода при обращении к внешнему репозиторию
  5. OpenNews: Доступна децентрализованная система отслеживания ошибок git-bug 0.9
  6. OpenNews: Выпуск системы управления исходными текстами Git 2.50
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/64279-git
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (107) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.3, Аноним (3), 18:35, 18/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Все говорят что раст это плохо. Но ведь runtime зависимости не будет. Problems, officer?
     
     
  • 2.20, Кошкажена (?), 21:05, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Не отпускает от предыдущей новости?
     
  • 2.35, Аноним (35), 23:20, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Проблема в Раст. Его тоже собрать надо. А сколько раз в год он релизится?
     
     
  • 3.37, Аноним (37), 23:35, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не столь важно, сколько раз. Важно, что ты будешь последовательно собирать каждый предыдущий. НУ, раз уж мы заговорили о сборке. Я вот обновил на 5 версий пару дней назад, что потребовало определённой возни. Проще было бинарный тулчейн стащить, но это не наш метод. Шланги тоже пришлось перебирать и вот это реальная проблема.
     
  • 2.63, Кошкажена (?), 05:34, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    1. Проблема со сборкой с нуля. Для этого надо тащить раст и весь его тулчейн. Для source-based дистрибутивов это сильная боль.
    2. Доп нагрузка на CI из-за нового тяжелого тулчейна.
    3. +1 яп в проект - это увеличение зоопарка технологий. Все прекрасно понимают, что весь С в ближайшем будущем никто не перепишет. Никто не любит скакать между технологиями в проекте.
     
     
  • 3.109, Аноним (-), 23:15, 20/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > 1. Проблема со сборкой с нуля. Для этого надо тащить раст и весь его тулчейн.
    > Для source-based дистрибутивов это сильная боль.

    Это также проблема для раскрутки платформ с ноля (bootstrap). Пересобирать _все_ версии Rust? С начала времет? Да вы издеваетесь господа!

    И не, бинари для новой платформы на деревьях не растут.

     

  • 1.4, Анонисссм (?), 18:38, 18/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    самая непонятная программа на свете это git
     
     
  • 2.5, myster (ok), 18:42, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    например? Что там непонятного?
     
  • 2.82, Аноним (82), 11:27, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Git - де-факто стандарт в индустрии разработки ПО. Все профессионалы уже давно Git поняли, один ты непонимающий сидишь до сих пор.
     
  • 2.110, Аноним (-), 23:15, 20/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > самая непонятная программа на свете это git

    Ну значит девелоп софта в тиме - не твое...

     

  • 1.6, Аноним (6), 18:43, 18/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    > В будущем ожидается переработка на Rust более значительны внутренних компонентов Git и добавление Rust в число обязательных сборочных зависимостей в Git 3.0.

    Всё, фризимся на 2.52

     
     
  • 2.14, Аноним (14), 20:06, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Зачем? Если раст будет полноценно поддерживаться в gcc без всякого копролита вроде llvm, то какая разница?
     
     
  • 3.15, Аноним (6), 20:20, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Хм... так-то да.
     
  • 3.38, Аноним (37), 23:39, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Это случится… Не скоро, но если случится, то останется решить только вопросы отсутствующего аби (впрочем, плюсы как-то существуют тоже) и динамической линковки.
     
  • 3.89, zionist (ok), 14:11, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ключевое слово - полноценно.
     
  • 2.59, Аноним (59), 04:48, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Гугл - хозяин интернетов. Майкрософт - хозяин десктопа. Оракл - хозяин серверов. Вот и стало всё почти как в 90х.
     

  • 1.7, xsignal (ok), 18:47, 18/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Гит только для ядра годится, потому что писался для этого и Торвальдсом под себя. Для обычных проектов есть куда более удобные системы хранения версий.
     
     
  • 2.8, Аноним (6), 18:53, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Гит только для ядра годится

    А только для линуксового ядра? Или для других ядер тоже годится?

     
     
  • 3.9, Аноним (9), 19:05, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Только линукс.
     
  • 3.10, Аноним (10), 19:12, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Не, ну если тебе нравится хэши запоминать и у тебя это хорошо получается, то можно и для других ядер тоже)
     
     
  • 4.11, Аноним (6), 19:14, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем их запоминать? Для удобства манипулирования их же можно сокращать до 8 первых символов, и даже в этом случае можно не запоминать.
     
  • 4.34, morphe (?), 23:10, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем их запоминать? Судя по комментариям опеннетные эксперты гит даже не трогали
     
     
  • 5.36, Аноним (36), 23:30, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Понятно, что на них иногда надо обращать внимание, копировать-вставлять и всё такое. Но запоминать-то их зачем?

    Это из той же области как и жалобы, что ipv6 плохо запоминаются.

     
     
  • 6.40, Аноним (37), 23:53, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Когда ищешь что-то и работаешь с историей, приходится запоминать. Да и осминожку мержить удовольствие то ещё (особенно выборочно откатывать).
     
     
  • 7.42, Аноним (36), 00:39, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В одной вкладке терминала git log, в другой git rebase --interactive, который повторяется на ветке до тех пор, пока всё не причешется. В конце сделать ребейз на родительскую ветку и потом можно мержить без выкрутасов.

    Возможно, у нас такого треша нет, чтобы нужно было всё время заниматься археологией.

     
  • 7.44, morphe (?), 01:06, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Когда ищешь что-то и работаешь с историей, приходится запоминать. Да и осминожку
    > мержить удовольствие то ещё (особенно выборочно откатывать).

    Если у тебя чот прям сложное - то дай коммитам имена (refs, ветки т.е) и пользуйся ими

    А вообще interactive rebase и в частности для осьминогов --onto и --rebase-merges в помощь.
    Однако если у вас слишком часто надо очень дофига мержить и ребейзить - то возможно есть смысл пересмотреть воркфлоу (= вы что-то делаете не так)/посмотреть на jujutsu (https://jj-vcs.github.io/jj/latest/), который сложные операции с историей реализует приятнее

     
     
  • 8.67, Аноним (67), 06:58, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сколько сУрьёзных слов А мог бы просто папочки в 7z создать ... текст свёрнут, показать
     
  • 5.68, Аноним (67), 06:59, 19/11/2025 Скрыто ботом-модератором     [к модератору]
  • +1 +/
     
     
  • 6.73, morphe (?), 07:57, 19/11/2025 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.12, Аноним (12), 19:17, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Но другие свободные альтернативы распределённых VCS загнулись.
     
  • 2.13, Аноним (13), 20:06, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    CVS был топчик!
     
     
  • 3.17, Аноним (17), 20:31, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Отвратительным он был. Вздохнул с облегчением после перехода на гит.
     
     
  • 4.69, Аноним (67), 07:00, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Единственным адекватным был. Хотя и тоже оверинжиниринг.
     
     
  • 5.83, Аноним (82), 11:35, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Нет. "Адекватным" CVS был разве что по сравнению с ужасами типа Microsoft Source Safe. SVN уже был значительно лучше CVS. А Git гораздо лучше SVN.
     
  • 5.98, Аноним (98), 01:44, 20/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Адекватным по сравнению с чем?
    С "Новая Папка 38"?

     
  • 3.21, Аноним (21), 21:12, 18/11/2025 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 4.26, Аноним (26), 21:28, 18/11/2025 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.18, Аноним (18), 20:48, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Неиронично, но для совсем мелких или даже средних, банальное версионирование аля новая_папка2 внезапно неплохо справляется с задачей. Подход очень простой, старые версии архивируются, изменения в коде можно подписывать в отдельном файле.
     
     
  • 3.22, Аноним (22), 21:14, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    От всей души надеюсь, что это сарказм
     
     
  • 4.27, Аноним (26), 21:30, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Все он верно пишет. Для каждой задачи свой инструмент. Если это простой не еоммандный проект, создать новую папку будет проще и быстрее.
     
     
  • 5.31, morphe (?), 23:05, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Разве что на хелловрот с тремя файлами, иначе даже в личных проектах образуется достаточно кода чтобы за ним надо было нормально следить
     
     
  • 6.56, Трахтенберг (?), 03:15, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Разве что на хелловрот с тремя файлами

    Судя по характеру комментариев, это твой максимум -- писать раздутые hello world. Хотя вроде ты и не индус, чтобы платили за количество строк кода. Подозрительно 🤔

     
  • 6.111, 12yoexpert (ok), 05:24, 21/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    обычно маленькие дети начинают копировать каталоги и создавать архивы, пока ещё боятся VCS. потом приходит понимание, что даже для хелловротов git init - первое, что нужно сделать
     
  • 5.41, _ (??), 00:03, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Тля, в Спарте вас бы со скалы ...

    Запоминай или прямо копи-пЭйсти:

    mkdir Суперпрога
    cd Суперпрога
    git init
    cat <<EOF >CoC.md
    Rust has a safe mem0ry management! Nyaaaaaaa!!!
    EOF
    git add --all
    git commit -m "Суперпрога B0rnCry!"
    git status
    git log

    И всё - ты уже белый человек, а не тварь дрожащая :-))))))

     
  • 4.45, morphe (?), 01:10, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > От всей души надеюсь, что это сарказм

    Если хоть раз приходилось сталкиваться с инфраструктурой не-айти компаний, где сайт и всё прочее делал племянник начальника - то можно понять что скорее всего не сарказм.

    Увы, но эффект Даннинга-Крюгера сильно распространён

     
     
  • 5.57, Трахтенберг (?), 03:16, 19/11/2025 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.76, Аноним (76), 10:06, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    +1. Например, Mercurial(Hg). Ума не приложу, каким надо быть дилетантом, чтобы выбирать Git! Самое кривое поделие со времён "линукса-ядра".
     
     
  • 3.84, Аноним (82), 11:39, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Git - де-факто стандарт в индустрии разработки ПО. Его используют не дилетанты, а профессионалы. А ты просто унылый хейтер-неасилятор.
     
     
  • 4.90, xsignal (ok), 14:51, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Его используют не дилетанты, а профессионалы

    Да уж... По работе регулярно наблюдаю, как с ним мучаются даже гуру Git'а

     
     
  • 5.104, Аноним (82), 17:20, 20/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, значит не такие уж они и гуру
     
  • 3.97, _ (??), 01:37, 20/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Например, Mercurial(Hg)

    Один нюанс(С) - может ты и не заметил, но он немножечко сдох(С) :(
    Не пережил переезд пыхтона с 2-ки на 3-ку ...

     

  • 1.16, Аноним (16), 20:20, 18/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Скоро гит по количеству строк кода догонит ядро линукса
     
     
  • 2.19, Аноним (19), 20:58, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Если в гите завёлся раст - точно догонит.
     
     
  • 3.49, Аноним (49), 02:23, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В меркуриале завелся ещё раньше

    https://www.mercurial-scm.org/help/topics/rust

     
  • 2.85, Аноним (82), 11:40, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А если этого не случится, ты извинишься за свою неправоту?
     
  • 2.114, Девелопер девяностых (?), 00:24, 22/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Так первая версия линух имела лишь ~10200 строк кода, думаю гит уже давно обогнал его ;)
     

  • 1.24, Сосед с перфоратором (?), 21:23, 18/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Слишком сложно и нагроможденно все становится. Скоро раздуют IT-пузырь до того, что понадобится отдельный специалист по git.
     
     
  • 2.62, Кошкажена (?), 05:31, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Скоро раздуют IT-пузырь до того, что понадобится отдельный специалист по git.

    Да нет, вместо gitops-инженера будет вайбgit.

     
     
  • 3.66, Аноним (67), 06:57, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Смешно будет, когда всех этих "инженеров" с гуманитарным образованием попрут, когда пузырь лопнет.
     
  • 2.77, Аноним (76), 10:09, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    По факту, так и есть. НИ ОДИН юзер гита не скажет "Я знаю весь гит" - ибо нереально. Что говорит о непомерной раздутости инструмента ради местечковых бонусов. Не говоря уже о том, что никто не смог заюзать гит без месяцев тренировки и ГУЯ. В противовес Hg, который прозрачен как логическая цепочка Сократа.
     
     
  • 3.86, Аноним (82), 11:43, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > никто не смог заюзать гит без месяцев тренировки и ГУЯ.

    Вызывающее неверная информация. Если ты на это не способен - говори за себя, только и всего.

    А ты все ключи ls наизусть знаешь? Или ls - тоже "непомерно раздутый инструмент"?

     
  • 3.91, Кошкажена (?), 16:07, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > По факту, так и есть. НИ ОДИН юзер гита не скажет "Я
    > знаю весь гит" - ибо нереально. Что говорит о непомерной раздутости
    > инструмента ради местечковых бонусов.

    Это всего лишь говорит о том, что инструментом можно пользоваться не залазя под капот.

     
  • 3.101, Аноним (101), 09:59, 20/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Не думаю что там нужны месяцы тренировок. В основном несколько основных комманд для создания коммитов, веток, мерджей, и возможно реверта коммитов. Историю же и вправду проще просматривать через гуи, но не более того. Очень просто инструмент на самом деле
     
  • 3.115, Аноним (115), 05:32, 22/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Врешь. Огромное количество народу пользуется гитом из консоли, потому что типовые сценарии требуют знания только git merge, git rebase, git add, git pull, git push, git checkout, git branch.
    Единственное, что неудобно делать из консоли - это конфликты решать, это удобно в GUI делать графическом, с цветовой раскраской блоков.
     

  • 1.28, Аноним (26), 21:32, 18/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Гит нужен исключительно для командной работы над очень крупными проектами на тысячи строк. Для всего остального быстрее и проще создавать новые папки. А теперь докажите, что это не проще. И я серьёзно.
     
     
  • 2.29, Аноним (6), 21:52, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > на тысячи строк

    может на сотню тысяч?

    Тысячи строк - это так-то и 2000 и 10000, что на крупный проект как-то не тянет.

     
     
  • 3.30, Аноним (26), 22:08, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для меня даже одна тысяча это очень много. Мои проекты (торговые боты для Polymarket) укладываются обычно в сотню. Максимум две сотни строк. Возможно потому, что я практикую подход к написанию кода от suckless.org.
     
     
  • 4.33, morphe (?), 23:08, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Короче пишешь питон скриптики на один файл, зачем маскировать это под какой-то мистический подход к написанию кода
     
     
  • 5.39, Аноним (37), 23:48, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да и вообще питон скриптики на один файл легко 10к строк набирают за вечер, если есть, что писать. Вот работать с ними ад во всех отношениях -- даже редактор неимоверно лагает.
     
     
  • 6.52, Трахтенберг (?), 03:02, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > один файл легко 10к строк набирают за вечер,

    Обычно так комментируют те, кто вообще ни одной строки не написал.

     
     
  • 7.71, Аноним (37), 07:37, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >> один файл легко 10к строк набирают за вечер,
    > Обычно так комментируют те, кто вообще ни одной строки не написал.

    Чепуха, навалить под 10к строк питона не проблема за день. Разгребать ещё неделю придётся конечно.

     
     
  • 8.80, Аноним2 (?), 10:30, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Для начала попробуй 10к строк текста набить и оцени насколько это нереально в ко... текст свёрнут, показать
     
     
  • 9.81, Аноним (37), 10:31, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Текст сложнее кода, сразу скажу А уж минимально осмысленный текст действительно... текст свёрнут, показать
     
  • 4.53, Трахтенберг (?), 03:04, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Для меня даже одна тысяча это очень много.

    Ты что, порядочный говн0кодер просто обязан на каждый пуK создавать классы и 100500 проверок обернутых в контейнер на докере с клиент-серверной архитектурой.

     
  • 3.54, Трахтенберг (?), 03:08, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >> на тысячи строк
    > может на сотню тысяч?
    > Тысячи строк - это так-то и 2000 и 10000, что на крупный
    > проект как-то не тянет.

    Вижу в твои словах попытку возвысить себя над окружающими, но сработало это в обратную сторону. Ведь чем больше строк в твоём коде, тем этот код ХУЖЕ. Любой инженер скажет, что вероятность ошибки/неисправности возрастает с количеством точек отказа, ну т.е. в твоём случае строк кода :-)

     
     
  • 4.92, Аноним (37), 18:42, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Вижу в твои словах попытку возвысить себя над окружающими, но сработало это
    > в обратную сторону. Ведь чем больше строк в твоём коде, тем
    > этот код ХУЖЕ. Любой инженер скажет, что вероятность ошибки/неисправности возрастает с
    > количеством точек отказа, ну т.е. в твоём случае строк кода :-)

    Вот, кстати, именно так рассуждают люди, не имеющие ни одного продукта за плечами. Любой продукт это минимум сотни тысяч строк. А средняя частота ошибок значение плюс-минус константное, но зависит от сложности (и всратости) логики, и никак не от количества строк.

     
     
  • 5.94, Аноним (-), 18:46, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > сотни тысяч строк

    Эмм… Ты вообще осознаешь какой это объем текста? Ты столько простого человекочитаемого текста за всю жизнь вряд ли напишешь, не говоря про код.

     
     
  • 6.95, Аноним (37), 18:54, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты когда-нибудь видел полноценные продукты? Средний программист пишет от 1 до 10 тысяч строк кода в день, какой это объём? Ерунда. Написать не проблема, сопровождать (рефакторить, дорабатывать, искать ошибки) -- проблема.
     
     
  • 7.99, nn (??), 08:33, 20/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    8 часов рабочий день * 60 минут в часе * 60 секунд в минуте = 12000
    твой программер пишет почти строку кода за секунду?
     
     
  • 8.100, Аноним (37), 08:54, 20/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ну почему, если писать 1 строку кода в секунду, за 8 часов получится 30000 И эт... текст свёрнут, показать
     
  • 2.32, morphe (?), 23:07, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Если с гитом умеешь работать, то мысли использовать копии директории даже не возникает
     
     
  • 3.51, Трахтенберг (?), 03:01, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Если с гитом умеешь работать, то мысли использовать копии директории даже не
    > возникает

    А если не умеешь и не собираешься работать в команде, то и учить не стоит, забивая голову всем подряд, но только не кодом. Да.

     
     
  • 4.64, Ангним (?), 06:31, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Для такого случая гуй придумали.
     
     
  • 5.65, Аноним (67), 06:56, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Всё равно создавать папки быстрее, чем работать с гуем гита. Просто потому что это забивание гвоздей микроскопом.
     
  • 4.96, Аноним (37), 20:05, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если ты работаешь 1 -- просто не публикуешь, гит всё ещё идеальный способ отслеживать историю. Он позволяет проследить логику изменений, что недоступно с копиями дерева файлов. А вот это действительно ценно. Если, конечно, не пихать всё в 1 коммит (осуждающе смотрю на разработчиков кед). Всё базовое взаимодействие с гитом досконально изучается за вечер, было бы там что учить.
     
     
  • 5.102, Аноним (101), 10:02, 20/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    1 коммит тоже зависит от контекста. Сделать один скваш из десяток  мусорных изменений, в единый информативный коммит - что такого плохого?
     
     
  • 6.103, Аноним (37), 10:23, 20/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > 1 коммит тоже зависит от контекста. Сделать один скваш из десяток  
    > мусорных изменений, в единый информативный коммит - что такого плохого?

    Коммиты должны быть такими, чтобы их можно было идентифицировать и откатить при необходимости в последствии. И не тратить кучу времени на идентификацию всех зависимых изменений в десятках коммитов и ручное удаление.

     
     
  • 7.106, Аноним (82), 17:31, 20/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Для этого и нужен сквош. Да и то не всегда помогает.
     
  • 4.107, Аноним (107), 19:02, 20/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Нет Если ты многократно вносишь изменения в свой скриптик на сотню строк, то gi... большой текст свёрнут, показать
     
  • 3.61, Кошкажена (?), 05:29, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Возникает, если у тебя бинарные данные или нужно бок о бок смотреть 2 версии проекта.
     
     
  • 4.72, morphe (?), 07:52, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Возникает, если у тебя бинарные данные или нужно бок о бок смотреть
    > 2 версии проекта.

    Для бинарных данных можно хоть свой мерждрайвер сделать (это не сложно, + есть готовые даже для libreoffice)/хоть smudge фильтр для преобразования их в не-бинарные для работы с ними как с текстом/хоть git annex для автоматического сохранения/выгрузки в/из S3 и работы с ним как с ссылокой/хоть git LFS для опять же хранения его как ссылки

    Бок о бок ты в гите можешь сравнить хоть 10 версий проекта, все инструменты для этого есть, можешь даже для каких-то инструментов сделать несколько рабочих деревьев через git worktree

     
     
  • 5.74, Кошкажена (?), 07:57, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >> Возникает, если у тебя бинарные данные или нужно бок о бок смотреть
    >> 2 версии проекта.
    > git annex для автоматического сохранения/выгрузки в/из S3

    Хочу локально хранить.


     
     
  • 6.75, morphe (?), 07:58, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Хочу локально хранить.

    Ну вот LFS, я ж его тоже упомянул

     
  • 2.46, Аноним (46), 01:44, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Создать проще, только вот спустя время разбираться в этом зоопарке папок будет куда сложнее.
     
     
  • 3.50, Трахтенберг (?), 02:59, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Создать проще, только вот спустя время разбираться в этом зоопарке папок будет
    > куда сложнее.

    Удалить все старое, оставив последний вариант. Зачем хранить все? Никогда гитом не пользовался для личных проектов.

     
     
  • 4.112, 12yoexpert (ok), 05:28, 21/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Никогда гитом не пользовался для личных проектов.

    это вообще не повод для гордости. когда (желаю тебе таки "когда", а не "если") начнёшь - тебе будет стыдно, что в принципе вслух такие глупости говорил

     
  • 2.47, penetrator (?), 01:50, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    гит корявый беспорно, но более лучшего у нас ничего пока нет
     
  • 2.78, Аноним (76), 10:12, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну нет. Даже если у тебя ДВА разраба на 1 проект, всё равно нужна DVCS (Mercurial). Потому что не всегда ты заливаешь "готовый код" - иногда у тебя сделано пол-фичи, но нужно "залить на сервер", т.к. у тебя ноут сдыхает! Сделал бранч и заливай хоть вирусы.
    Собственно, "бранчи" и есть краеугольный камень любой VCS - они позволяют всем залить свой кусок кода, но не портить "главный проект".
     
  • 2.87, Аноним (82), 11:51, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Гит нужен исключительно для командной работы над очень крупными проектами на тысячи строк.

    Тысячи строк - это "очень крупный проект"? По мне, так это очень мелкий проект.

     
     
  • 3.93, Аноним (-), 18:43, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > По мне, так это очень мелкий проект.

    Так говорить может только тот, кто не осилил даже тысячу строк простого текста, не говоря о коде и программировании.

     
     
  • 4.105, Аноним (82), 17:28, 20/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Так говорить может только тот, кто только и может, что строить предположения, кто и что может говорить. А сделать что-то реальное вместо своей болтовни не способен.
     

  • 1.43, Аноним (43), 00:47, 19/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Ну и разве это не bloat?
     
     
  • 2.55, Трахтенберг (?), 03:10, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ну и разве это не bloat?

    Сферический в вакууме. Да. Он самый. Совсем скоро в это недоразумение будет вбухано человекочасов большая чем в само ядро :-)

     

  • 1.58, ddwrt (?), 03:59, 19/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Сабж — классический хрестоматийный пример оверинжиниринга.
     
     
  • 2.70, Аноним (67), 07:01, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Сабж — классический хрестоматийный пример оверинжиниринга.

    Хрестоматийный пример нинужного.

     
  • 2.79, Аноним (76), 10:14, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не-не... архитектура там как раз простая (хоть и кривая), тут наглядный пример overbloated code. Overengineering - это когда print "hello world" решается через фабрики классов, DI и с тысячей тестов. :)
     

  • 1.60, Кошкажена (?), 05:28, 19/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    1. В целом git закончен, так что даже фиксация версии не должна ничего сломать.
    2. Есть got.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2025 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру