The OpenNET Project / Index page

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

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

19.08.2025 07:09

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

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

  • Повышена производительность команд "git push" и "git fetch" в репозиториях с большим числом ссылок. Ускорение обеспечено за счёт обновления ссылок в пакетном режиме, в котором в одной транзакции обрабатывается сразу несколько ссылок, вместо создания отдельной транзакции для обновления каждой ссылки. Оптимизация существенно увеличила скорость работы бэкенда "reftable", которые теперь обгоняет по производительности бэкенд "files" Например, в тестовом репозитории с 10 тысячами ссылок производительность "git fetch" при использовании бэкенда "reftable" увеличилась в 22 раза, а при использовании бэкенда "files" - в 1.25 раза. Для "git push" прирост составил 18 и 1.21 раз, соответственно.
  • Предложен новый метод упаковки в pack-файлах частей репозитория, не связанных с отслеживанием недостижимых объектов, на которые в репозитории отсутствуют ссылки (не ссылаются ветки или теги). Информация о недостижимых объектах хранится в отдельных pack-файлах ("cruft packs"), что приводило к необходимости их отражения в многопакетных индексах MIDX (multi-pack index) для охвата объектов, которые изначально были недостижимы и хранились только в cruft-пакете, но затем стали достижимы после ссылающегося на них коммита.

    В новой версии при переупаковке pack-файлов обеспечено сохранение дополнительных копий достижимых объектов, хранимых только cruft-файлах. Подобное изменение гарантирует, что в наборе pack-файлов, используемых для хранения достижимых объектов, не содержится объектов, ссылающихся на другие объекты, хранимые вне этого набора. Для исключения из многопакетных индексов (MIDX) недостижимого содержимого cruft-файлов предложена настройка "repack.MIDXMustContainCruft", позволяющая заметно сократить размер подобных индексов. Включение настройки в репозитории GitHub позволило сократить размер MIDX-индексов на 38%, ускорить запись в MIDX-индексы на 35% и повысить производительность чтения на 5%.

  • В команду "git pack-objects" добавлена опция "--path-walk", включающая новый метод сбора информации об объектах при переупаковке pack-файлов. Вместо обхода объектов в порядке ревизий, при использовании режима "--path-walk" объекты перебираются через обход файловых путей, что позволяет разом упаковывать все объекты с одним и тем же файловым путём. Подобный подход даёт возможность исключить эвриситку, использующую хэширование для определения связи объекта с его файловым путём, а также избавиться от сортировки объектов перед упаковкой. При использовании режима "--path-walk" размер генерируемых pack-файлов получается значительно меньше, чем при группировке объектов при помощи хэшей.
  • Определён формат для обмена сохранёнными состояниями рабочего дерева и индексов в репозитории, создаваемыми при помощи команды "git stash". Новый формат позволяет кодировать сохранённые изменения (stash-записи) в виде последовательности коммитов. Для импорта и экспорта предложены подкоманды "git stash import" и "git stash export", которые можно использовать для переноса сохранённых состояний с одной системы на другую и выполнения операций push или pull с этими состояниями как с обычными ветками или тегами.
    
       git stash export --to-ref refs/stashes/my-stash
       git push origin refs/stashes/my-stash
       ...
       git fetch origin '+refs/stashes/*:refs/stashes/*'
       git stash import refs/stashes/my-stash
    
  • В команде "git cat-file", выводящей содержимое заданных объектов, при использовании опций "--batch" и "--batch-check" реализована возможность отображения информации об отсутствующих объектах (например, из-за повреждения репозитория) и субмодулях. Ранее при указании пути у субмодулю команда "git cat-file --batch-check" выводила "missing", а теперь покажет идентификатор объекта.
  • В команде "git log" задействованы оптимизации на основе фильтров Блума для ускорения поиска в истории изменений при указании фильтров с несколькими файловыми путями, например, "git log -- path/to/a path/to/b".
  • Стабилизированы команды "git switch" и "git restore", которые с 2019 года рассматривались как экспериментальные. Команды преподносятся как современные эквиваленты "git checkout", разделяющие такие малосвязанные возможности данной команды, как манипуляция ветками (переключение и создание) и восстановление файлов в рабочем каталоге.
  • Объявлена устаревшей и намечена к удалению в ветке Git 3.0 команда "git whatchanged", эквивалентная "git log --raw".
  • В команду "git for-each-ref" добавлена опция "--start-after", которая может применяться совместно с опцией "--count" для организации постраничного вывода.
  • В команды "git merge" и "git pull" добавлена опция "--compact-summary" для использования компактного формата сводной информации об изменениях вместо формата diffstat.
  • В кодовой базе Git разрешено использование ключевого слова "bool", появившегося в стандарте C99. Также документированы некоторые возможности C99, экспериментально используемые в Git (например, в середине 2026 года планируют разрешить применение конструкций "(struct foo){ .member = value };"). Компилятор с поддержкой C99 является обязательным для Git c 2021 года, но возможности спецификации C99 внедряются крайне осторожно для сохранения совместимости с компиляторами, лишь частично поддерживающими данный стандарт.
  • В правила приёма патчей внесены изменения, разрешающие отправку патчей под псевдонимом, а не только под настоящим именем разработчика. Изменение соответствует правилам приёма патчей в ядро Linux.
  • Обновлён список нарушающих совместимость изменений, которые будут применены в ветке Git 3.0. Из значительных изменений в предстоящем выпуске Git 3.0 отмечается переход по умолчанию на идентификаторы объектов на основе алгоритма хэширования SHA-256 при инициализации новых репозиториев и задействование формата "reftable" для хранения в репозитории ссылок на ветки и теги (задействовано блочное хранилище от проекта JGit, оптимизированное для хранения очень большого числа ссылок).


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


Обсуждение (55) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.6, Аноним (6), 10:31, 19/08/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Трудно представить большее Легаси.
     
     
  • 2.20, Аноним (20), 11:06, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Почему трудно? Легко, большее легаси это - cvs, svn, hg, perforce
     
     
  • 3.32, Аноним (-), 11:54, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Почему трудно? Легко, большее легаси это - cvs, svn, hg, perforce

    Ща я вас всех уделаю. Microsoft TFS (Team Foundation Server). Вот это я понимаю - легаси. VCS в котрой принципиально нельзя редактировать 1 и тот же файл, на уровне блокировок просто.

     
     
  • 4.35, mogwai (ok), 12:01, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >VCS в котрой принципиально нельзя редактировать 1 и тот же файл, на уровне блокировок просто

    В это время 1С с их Хранилищем конфигураций: "это почему это - легаси?"

     
  • 4.43, andreyche (?), 12:41, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А про Microsoft Visual SourceSafe слыхал? "База" просто расшарена по сети как сетевая папка с доступом на запись всем
     
     
  • 5.45, X512 (?), 12:58, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    С Git так тоже можно. 'git clone file:///path/to/repo' и вперёд.
     
  • 5.54, Аноним (-), 14:40, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > А про Microsoft Visual SourceSafe слыхал? "База" просто расшарена по сети как
    > сетевая папка с доступом на запись всем

    Краем уха, да. А вон то зачетная штука. Дев в проекте заболел? А вот иди ищи теперь админа, локи с его файлов сбить. Или кукуй без редактирования. Вот это я понимаю, продуктивный девелоп. А уж вещи типа 3-way merge? Черт, про такие навороты индусам MS рассказать забыли.

     
  • 2.23, Аноним (-), 11:20, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Трудно представить большее Легаси.

    Что-то у тебя анон  плохо с фантазией. Bitbaker, perforce, cvs, svn. Hg, наконец.

     
     
  • 3.30, Аноним (30), 11:46, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Что-то у тебя анон  плохо с фантазией

    Анон не понимает значения слова "легаси".

     
     
  • 4.31, Аноним (-), 11:52, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >> Что-то у тебя анон  плохо с фантазией
    > Анон не понимает значения слова "легаси".

    Все вон то перечисленное - это легаси :D

     
  • 3.39, None (??), 12:25, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    BitKeeper, Bazaar
     
  • 3.51, Вася Пупкин (?), 14:21, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    hg с гитом ровестники тащемтa
     
     
  • 4.55, Аноним (-), 14:43, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > hg с гитом ровестники тащемтa

    Но один legacy а другое нет. Так бывает, да. Legacy в софтострое - это по "выпало из употребления". Если вы хотели таксопарк замутить, всюду уже чуть не беспилотные такси, а вам достались брички и лошади - не так уж важно что лошади молодые, брички - новее чем вооооон тот рыдван соседнего таксиста.

     

  • 1.7, Аноним (7), 10:31, 19/08/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –14 +/
    Добрый день! Почему программисты не пользуются SVN, а пользуются вендор-локом GIT? Неужели компетенции не хватает, или же все жуют жвачку, только лишь потому что - мода такая?
     
     
  • 2.11, 52 (?), 10:36, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Из наиболее известного − репозиторий плеера qmmp работает на SVN, то есть не все используют git
     
  • 2.12, анонимас (?), 10:38, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    почему не используют сохранение по папкам с именами версий а хотят вендор-лок SVN ? неужто из за того что мода такая, а?
     
  • 2.13, Аноним (20), 10:38, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Я думаю программисты не пользуются SVN потому git удобнее и фичастее, а еще он децентрализованный, а значитт позволяет работать со скаченными исходниками без подключения к Интернету.
     
     
  • 3.62, Аноним (62), 15:35, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Сейчас просто нет бесплатных хостингов с svn, поэтому тупо некуда деваться.
     
  • 2.14, Аноним (14), 10:40, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +9 +/
    >Почему программисты не пользуются SVN

    Потому что ушли с этого г-на на GIT и вспоминают этот кошмар как страшный сон.

     
     
  • 3.28, Аноним (-), 11:34, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Потому что ушли с этого г-на на GIT и вспоминают этот кошмар
    > как страшный сон.

    Удваиваю этого анона. В жизни больше svn использовать не буду. В git можно девелопать как белый человек, хот 100% локально, быстро делать git bisect и что там еще - без постоянной выкачки половины проекта заново, что бывает мучительно тормозно если это не соседний сервак на гигабитной сетке.

     
  • 2.15, anonymous (??), 10:44, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ты, видно, не очень часто работаешь с SVN, не знаешь, что такое ветки мержить в SVN.
     
     
  • 3.61, Аноним (62), 15:33, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Я тебя удивлю, но также, как и в git, через svn merge
     
  • 2.25, Аноним (25), 11:23, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Добрый день! Почему программисты не пользуются SVN, а пользуются вендор-локом GIT? Неужели
    > компетенции не хватает, или же все жуют жвачку, только лишь потому
    > что - мода такая?

    Я вот юзаю git на вон той репе с лично моим проектом - локально. Во я себя заведорлочил то. А в чем бенефит? А вот мне не надо ставить какие там сервера в обязаловку. Я пожалуй не против такого "вендорлока". Сам же и буду как единоличный вендор решать сколько живет моя приблуда.

    В качестве точки обмена в вебе опять же несложно гит нарулить. И в отличие от svn все копии репы равнопрравны и могут прекрасно наигировать по всей истории без того сервера. А в SVN на большом проекте нечто типа git bisect вообще задолбаешься нахрен делать, когда оно половину интернета выкачивает на каждую ревизию заново.

     
     
  • 3.63, Аноним (62), 15:37, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >лично моим проектом - локально

    Я тебя может удивлю, но svn давно умеет работать локально. Просто репу придётся держать в отдельной папочке.

     
  • 2.29, Аноним (-), 11:43, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что:
    1) "мы тоже хотим быть как боги". Ну, то есть как разработчики ядра;
    2) гитхаб сделал git доступным для каждой домохозяйки

    Но всё же другие системы управления исходниками гораздо более для людей, главное не сужать свой кругозор до SVN.

     
     
  • 3.33, Аноним (-), 11:55, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Но всё же другие системы управления исходниками гораздо более для людей,

    Не стоит путать ящеров, домохозяек и домохозяек-ящеров с людьми.

     
  • 2.38, Аноним (20), 12:21, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > вендор-локом GIT

    и как он вендор-лочит? Вот я установил себе гит на комп, создал с его помощью репу. Я на кого завендорлочился?

     
     
  • 3.46, Аноним (30), 13:05, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > и как он вендор-лочит?

    Боюсь, ответа от него мы не увидим: очевидно же, что это был наброс на вентилятор.

     

  • 1.10, 52 (?), 10:33, 19/08/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    То что git написан в основном на C90 показывает какой git капролит
     
     
  • 2.16, Аноним (6), 10:47, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Единственный нормальный комментарий во всей ветке.
     
     
  • 3.21, Аноним (21), 11:12, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    4 ошибки в одной строке текста опровергают Вашу гипотезу.
     
  • 2.18, Обычный человек (?), 10:50, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Расскажите, что написано не на Си или не использует либы написанные не на Си, и при этом не копролит? Будем вместе с вами переходить не на копролит.
     
     
  • 3.22, Аноним (21), 11:13, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Квалификация позволяет.
     
  • 3.52, Вася Пупкин (?), 14:23, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    jujitsu (https://github.com/jj-vcs/jj)
     
  • 3.60, 52 (?), 15:04, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Дело не в Си, а в C90. Ещё бы на ANSI C писали бы, когда в ходу C17 или хотябы C11
     
     
  • 4.64, AnoNim (?), 15:51, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    C90 это и есть ansi c (c89), только его международная (iso) версия. Там правок между ними, кот наплакал!;)
     
  • 2.26, Аноним (-), 11:24, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > То что git написан в основном на C90 показывает какой git капролит

    А то что ты даже "копролит" правильно написать не можешь - показывает уровень. Это от слова copr - как там его федора расшифровывает. Шутка, но в каждой шутке... :)

     
  • 2.40, Аноним (40), 12:29, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    За шо хэйт?
     

  • 1.24, Аноним (24), 11:22, 19/08/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >отмечается переход по умолчанию на идентификаторы объектов на основе алгоритма хэширования SHA-256

    А протокол передачи на remote и поддержку в forge-ах они реализовали? Или предлагают перейти на воркфлоу с патчами, как в ядре linux?

     
     
  • 2.27, Аноним (-), 11:25, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > А протокол передачи на remote и поддержку в forge-ах они реализовали? Или
    > предлагают перейти на воркфлоу с патчами, как в ядре linux?

    Куды эти форжи денутся? Запилят как зайчики.

     
     
  • 3.42, Аноним (24), 12:36, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Да, гит будут пилить вместо авторов гита. Не, просто дистры перестанут обновлять гит.
     

  • 1.34, Анон28679234 (?), 11:58, 19/08/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У меня это какой-то лютый когнитивный диссонанс вызывает

    С одной стороны это backbone всей it индустрии и я этим отличным инструментом пользуюсь каждый день на 110%.

    С другой стороны в этой версии разрешили использовать стандарт которому не 35 лет, а всего 25(!) и то только частично

    Буквально пару версий назад писали что наконец-то git по окончании своей работы не тупо забивает на очистку памяти а правильно освобождает память как положено. И мол именно это блочило git от того чтобы завернуть его в dll и поставлять в таком виде всяким приложениям с gui потому что если консольное приложение в конце теч'т, то как бы пофиг, но для dll это проблема.

    Как так вышло что то что является фундаментом качественного кода и принципиально важной вещью, для разработчиков git всего лишь несущественная рекомендация которую начали соблюдать только потому что есть план заворачивать это все в dll ¯\_(ツ)_/¯

    Читать git release notes - это для смелых духом

     
     
  • 2.36, Аноним (30), 12:10, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > И мол именно это блочило git от того чтобы завернуть его в dll и поставлять в таком виде всяким приложениям с gui

    libgit2 же всегда для этого был.

     
     
  • 3.37, Анон28679234 (?), 12:13, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Я ссылаюсь на вот эту публикацию:
    https://github.blog/open-source/git/highlights-from-git-2-48/#memory-leak-free
     
  • 2.47, Аноним (47), 13:22, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Очевидно главное целеполагание.

    Гит должен работать на всех доступных системах.

    Вот и будет работать на системах 25-летней давности.

    А по поводу освобождения памяти.

    В Си для простых структур делать его легко - для сложных - тяжко.

    Сначала заморачивались на функциональность. И никто не мешает вызывать утилиты с нужными опциями из своих программ. Линус так вообще шареные библиотеки недолюбливает. Но это его личные тараканы.

     
     
  • 3.50, Анон28679234 (?), 14:00, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    я как-то очень смутно себе представляю работающую систему которой 25 лет и в которой реально что-то разрабатывают на git. Думаю количество таких кейсов исчезающе мало и место им или в музее или на ретро выставке. А даже если таких кейсов в мире больше 1к, не вижу причин почему бы им не посидеть на более старых версиях git, если есть такая необходимость.

    Потому не вижу обоснованных причин, почему git должен учитывать такие кейсы при разработке

     
     
  • 4.56, Аноним (-), 14:46, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > я как-то очень смутно себе представляю работающую систему которой 25 лет и
    > в которой реально что-то разрабатывают на git.

    Linux Kernel не подойдет? Правда чем его юзкейсы такие особенные - хз.

     
  • 4.58, Аноним (47), 14:50, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Потому не вижу обоснованных причин, почему git должен учитывать такие кейсы при разработке

    Как зрячий может объяснить слепому от рождения цвет заката?

     
     
  • 5.65, Анон28679234 (?), 16:10, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Как портируете git на абак, можем продолжить разговор
     
     
  • 6.66, Аноним (47), 16:19, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Если нельзя разглядеть монету на расстоянии пяти километров то зачем зрение?
     

  • 1.41, Аноним (41), 12:34, 19/08/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Компилятор с поддержкой C99 является обязательным для Git c 2021 года, но возможности спецификации C99 внедряются крайне осторожно для сохранения совместимости с компиляторами, лишь частично поддерживающими данный стандарт.

    Шёл 27-й год со времени принятия C99... А некоторые компиляторы до сих пор  лишь частично реализовали его поддержку.

     
     
  • 2.44, Анон28679234 (?), 12:56, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Может уже и не реализуют никогда? Может там bus factor?
     
  • 2.48, Аноним (47), 13:25, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Шёл 27-й год со времени принятия C99... А некоторые компиляторы до сих пор  лишь частично реализовали его поддержку.

    В старых системах компиляторы старые. А git должен работать везде.

    И за такой подход его надо в качестве учебника использовать.

    Что бы кандидаты в нормальные программисты учились как надо большие проекты разрабатывать.

     
     
  • 3.53, Анон28679234 (?), 14:37, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > git должен работать везде.

    Ну пусть старые системы и сидят на старой версии git - он у них будет работать
    Что-то мне подсказывает что если ребята не обновляют оборудование по 25 лет, то и свежий git им погоды не сделает

    > Что бы кандидаты в нормальные программисты учились как надо большие проекты разрабатывать.

    Думаю это сверхобобщение. Далеко не все большие проекты должны брать пример с git и разрабатываться в такой манере

     
     
  • 4.57, Аноним (47), 14:48, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > если ребята не обновляют оборудование по 25 лет

    С чего вы так решили? ОС и оборудование - несколько разные вещи.

    > Думаю это сверхобобщение. Далеко не все большие проекты должны брать пример с git и разрабатываться в такой манере

    Можно и не так. Только тогда надо смирится с минусами, вытекающими из-за отказа от "такой манеры".

     

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



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

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