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 обязательно


Обсуждение (84) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.3, Аноним (3), 18:35, 18/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Все говорят что раст это плохо. Но ведь 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 [^] [^^] [^^^] [ответить]  
  • +1 +/
    1. Проблема со сборкой с нуля. Для этого надо тащить раст и весь его тулчейн. Для source-based дистрибутивов это сильная боль.
    2. Доп нагрузка на CI из-за нового тяжелого тулчейна.
    3. +1 яп в проект - это увеличение зоопарка технологий. Все прекрасно понимают, что весь С в ближайшем будущем никто не перепишет. Никто не любит скакать между технологиями в проекте.
     

  • 1.4, Анонисссм (?), 18:38, 18/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    самая непонятная программа на свете это git
     
     
  • 2.5, myster (ok), 18:42, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    например? Что там непонятного?
     
  • 2.82, Аноним (82), 11:27, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Git - де-факто стандарт в индустрии разработки ПО. Все профессионалы уже давно 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 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Зачем? Если раст будет полноценно поддерживаться в gcc без всякого копролита вроде llvm, то какая разница?
     
     
  • 3.15, Аноним (6), 20:20, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хм... так-то да.
     
  • 3.38, Аноним (37), 23:39, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Это случится… Не скоро, но если случится, то останется решить только вопросы отсутствующего аби (впрочем, плюсы как-то существуют тоже) и динамической линковки.
     
  • 3.89, zionist (ok), 14:11, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ключевое слово - полноценно.
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Гит только для ядра годится

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

     
     
  • 3.9, Аноним (9), 19:05, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Только линукс.
     
  • 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 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Зачем их запоминать? Судя по комментариям опеннетные эксперты гит даже не трогали
     
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Когда ищешь что-то и работаешь с историей, приходится запоминать. Да и осминожку
    > мержить удовольствие то ещё (особенно выборочно откатывать).

    Если у тебя чот прям сложное - то дай коммитам имена (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 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Отвратительным он был. Вздохнул с облегчением после перехода на гит.
     
     
  • 4.69, Аноним (67), 07:00, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Единственным адекватным был. Хотя и тоже оверинжиниринг.
     
     
  • 5.83, Аноним (82), 11:35, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Нет. "Адекватным" CVS был разве что по сравнению с ужасами типа Microsoft Source Safe. SVN уже был значительно лучше CVS. А Git гораздо лучше SVN.
     
  • 3.21, Аноним (21), 21:12, 18/11/2025 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 4.26, Аноним (26), 21:28, 18/11/2025 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.18, Аноним (18), 20:48, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Неиронично, но для совсем мелких или даже средних, банальное версионирование аля новая_папка2 внезапно неплохо справляется с задачей. Подход очень простой, старые версии архивируются, изменения в коде можно подписывать в отдельном файле.
     
     
  • 3.22, Аноним (22), 21:14, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    От всей души надеюсь, что это сарказм
     
     
  • 4.27, Аноним (26), 21:30, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Все он верно пишет. Для каждой задачи свой инструмент. Если это простой не еоммандный проект, создать новую папку будет проще и быстрее.
     
     
  • 5.31, morphe (?), 23:05, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Разве что на хелловрот с тремя файлами, иначе даже в личных проектах образуется достаточно кода чтобы за ним надо было нормально следить
     
     
  • 6.56, Трахтенберг (?), 03:15, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Разве что на хелловрот с тремя файлами

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

     
  • 5.41, _ (??), 00:03, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тля, в Спарте вас бы со скалы ...

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

    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 [^] [^^] [^^^] [ответить]  
  • +/
    > Его используют не дилетанты, а профессионалы

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

     

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

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

     
  • 2.85, Аноним (82), 11:40, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А если этого не случится, ты извинишься за свою неправоту?
     

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

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

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

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

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

     

  • 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 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > один файл легко 10к строк набирают за вечер,

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

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

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

     
     
  • 8.80, Аноним2 (?), 10:30, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Для начала попробуй 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, что на крупный
    > проект как-то не тянет.

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

     
  • 2.32, morphe (?), 23:07, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если с гитом умеешь работать, то мысли использовать копии директории даже не возникает
     
     
  • 3.51, Трахтенберг (?), 03:01, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Если с гитом умеешь работать, то мысли использовать копии директории даже не
    > возникает

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

     
     
  • 4.64, Ангним (?), 06:31, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Для такого случая гуй придумали.
     
     
  • 5.65, Аноним (67), 06:56, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Всё равно создавать папки быстрее, чем работать с гуем гита. Просто потому что это забивание гвоздей микроскопом.
     
  • 3.61, Кошкажена (?), 05:29, 19/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Возникает, если у тебя бинарные данные или нужно бок о бок смотреть 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 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Создать проще, только вот спустя время разбираться в этом зоопарке папок будет
    > куда сложнее.

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

     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    > Гит нужен исключительно для командной работы над очень крупными проектами на тысячи строк.

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

     

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

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

     

  • 1.58, ddwrt (?), 03:59, 19/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сабж — классический хрестоматийный пример оверинжиниринга.
     
     
  • 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.
     
  • 1.88, Аноним (82), 11:54, 19/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Git - лучшая система контроля версий, когда-либо созданная человечеством
     

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



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

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