The OpenNET Project / Index page

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

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

11.01.2025 21:31

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

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

  • Реализована возможность сборки с использованием сборочной системы Meson, в дополнение к GNU Make и CMake. Для сборки Git теперь можно использовать команду "meson setup build && ninja -C build". Отмечается, что Makefile, применяемый при использовании GNU Make, разросся до 3887 строк и не так прост, как хотелось бы. Инструментарий Meson упрощает работу с системой сборки, удобен для кросс-платформенных сборок и делает сборку более доступной для новичков или разработчиков, не имеющих опыта работы с утилитой Make. Прекращать поддержку Make и CMake в обозримом будущем не планируется.
  • Добавлены сборочные опции, позволяющие использовать альтернативные реализации хэша SHA-1 при вычислении контрольных сумм, используемых для проверки целостности блоков данных в pack-файлах. Производительность вычисления контрольных сумм имеет большое значение, например, на их вычисление при клонировании репозитория с ядром Linux тратится около 78% процессорного времени. Используемая по умолчанию реализация включает дополнительные проверки коллизий и защиту от атак на SHA-1, таких как SHAttered и Shambles. Подобная защита, потребляющая дополнительные ресурсы, имеет смысл только при использовании SHA-1 в криптографических целях и бесполезна при проверке целостности индексных данных.

    Для сборки Git с более быстрой реализацией SHA-1, не пригодной для криптосистем, предложена серия опций *_UNSAFE, например, "OPENSSL_SHA1_UNSAFE". В GitHub сборка с упрощённым SHA-1 позволила на 10-13% повысить производительность операций извлечения и клонирования данных.

  • Добавлена возможность использования в команде "range-diff" опции "--remerge-diff", позволяющей показать отличия между общим результатом слияния и фактическими данными, отражёнными в коммите после обработки команды "merge". При использовании опции "--remerge-diff" различия между разрешениями конфликтов не разделяются для каждой родительской ветки, а показываются общие различия между файлом, имеющим конфликты слияния, и файлом, в котором конфликты решены. В контексте команды "range-diff" новая опция может оказаться полезной для сравнения наборов коммитов после переноса последовательности коммитов командой "rebase" с опцией "--rebase-merges".
  • Добавлена возможность запуска тестового набора Git с включением режима выявления утечек памяти. Так как git предоставляет утилиты, завершающие работу после выполнения вызванной функции, утечки памяти раньше не рассматривались как большая проблема. Необходимость полного устранения утечек памяти стала актуальной после начала работы над выносом внутренней функциональности в отдельную библиотеку, которая может применяться в длительно работающих процессах.
  • Началось формирование списка устаревших режимов и возможностей, поддержку которых планируют прекратить в будущем. Предполагается, что удаление устаревшей функциональности произойдёт в выпуске Git 3.0, в который войдут изменения, нарушающие обратную совместимость.
  • Продолжена оптимизация работы команды "git for-each-ref", выводящей список ссылок в репозитории. Оптимизация, объединяющая обработчики для фильтрации ссылок и форматирования вывода, теперь применяется не только для неотсортированного вывода, но и при указании опции "--sort".
  • Улучшена реализация бэкенда "reftable" с блочным хранилищем для эффективного хранения в репозитории ссылок на ветки и теги. Reftable позволяет значительно ускорить поиск, чтение и запись в репозиториях с очень большим числом ссылок. В новой версии прекращено обращение к некоторым вспомогательным API для дальнейшего исключения библиотеки libgit из числа сборочных зависимостей. Реализована адаптивная обработка ошибок, возвращаемых функциями выделения памяти (нехватка памяти теперь не приводит к аварийному завершению работы). Ускорены операции создания ссылок и снижено потребление памяти.
  • В реализации частичного клонирования решены проблемы, приводившие к зацикливанию и повреждению репозитория после выполнения команды "git gc".
  • При выполнении команды "git fetch <remote>" в случае отсутствия на локальной системе "refs/remotes/<remote>/HEAD" и наличия на другой стороне ветки, на которую ссылается HEAD, "refs/remotes/<remote>/HEAD" теперь перенаправляется на эту ветку. Для управления синхронизацией "refs/remotes/<remote>/HEAD" со значением HEAD на другой стороне соединения добавлена настройка remote.<remote>.followRemoteHEAD".
  • Добавлена настройка "remote.<name>.serverOption" аналогичная опции командной строки "--serverOption=<value>".
  • В команде "git rebase --rebase-merges" по возможности обеспечено использование имён веток в качестве меток.
  • В команды 'git notes add' и 'git notes append' добавлен флаг '-e', открывающий примечание во внешнем текстовом редакторе, указанном через переменную окружения GIT_EDITOR.
  • Улучшена совместимость с GCC 15 и стандартом C23.
  • Прекращена поддержка старых версий libcURL и Perl.


  1. Главная ссылка к новости (https://github.blog/open-sourc...)
  2. OpenNews: Выпуск системы управления исходными текстами Git 2.46
  3. OpenNews: mergiraf - AST-ориентированный инструмент для трёхстороннего слияния в Git
  4. OpenNews: Выпуск git-совместимой системы управления версиями Got 0.100
  5. OpenNews: Пять уязвимостей в Git, среди которых одна критическая и две опасные
  6. OpenNews: Проект gittuf развивает систему криптографической защиты репозиториев Git
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/62545-git
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (61) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 22:21, 11/01/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Предполагается, что удаление устаревшей функциональности произойдёт в выпуске Git 3.0, в который войдут изменения, нарушающие обратную совместимость.

    Должно быть только так и никак иначе. А то куда ни гляну. В минорных релизах ломают совместимость с обоснованием "оно уже год депрекейтед" (ну или 3 года, совершенно неважно).

     
     
  • 2.3, Хру (?), 22:45, 11/01/2025 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Так эта.. "живи быстро, умри молодым"…  Тьфу, не оно! "Обновляйся быстрее, живи свежО". Вот и ломают :)
     
  • 2.4, Аноним (4), 00:20, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Не только лишь все научились соблюдать semver, увы.
     
  • 2.24, Аноним (24), 14:21, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >"оно уже год депрекейтед" (ну или 3 года, совершенно неважно).

    Точно. Вот и в ядре выпиливать устарешие архитектуры и устаревшие(?) файловые системы следовало бы в 7.0

     
  • 2.62, Аноним (62), 14:36, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Кому должно Смотри, я разрабатываю библиотеку Допустим, выкидываю поддержку ка... большой текст свёрнут, показать
     

  • 1.5, Аноним (5), 01:41, 12/01/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Лучший?
     
     
  • 2.7, 12yoexpert (ok), 03:22, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +4 +/
    порог входа слишком высок, ни один веб-сеньор ещё не побежал сломя макбук переписывать на раст
     
     
  • 3.8, 12yoexpert (ok), 03:34, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    UPD: а хотя уже побежали

    https://github.com/GitoxideLabs/gitoxide

    9K звёзд, 14K коммитов и 1940 релизов (тысяча девятьсот сорок). но пока что только клонировать умеет, и то не всё

     
     
  • 4.11, Аноним (4), 05:50, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если почитать внимательнее, то умеет он сильно больше, чем клонировать. Он же не с командлайновой тузлы начал, а с реализации всех внутренних механик гита в виде библиотеки. Когда все библиотеки будут закончены (а они закончены почти все), тогда, используя их будет и полноценная CLI.

    Я за ними уже года три слежу, что бы свой гитовый сервер запилить, влезающий на дохлую виртуалку.

     
     
  • 5.13, sergeyb (ok), 08:44, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Можно уже использовать gotwebd/gotd для дохлой виртуалки.
     
     
  • 6.20, Аноним (4), 12:17, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > gotd does not yet support version 2 of the Git network protocol.

    Оксайд-то как раз вторую делает.

     
  • 6.26, Аноним (-), 15:16, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Можно уже использовать gotwebd/gotd для дохлой виртуалки.

    Для дохлой виртуалки можно и cgit так то. Даже если ее совсем вынесут - там все равно кроме этого гита брать нечего. А попытки комитов ессно будут светиться на радаре как ошпаренные. И ради чего все это жданье, спрашивается?

     
  • 5.23, 12yoexpert (ok), 12:30, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Я за ними уже года три слежу, что бы свой гитовый сервер запилить, влезающий на дохлую виртуалку.

    я не ждал тжри года, пока что-то доделают на расте, взял cgit на сишечке и пользуюсь

    > Если почитать внимательнее, то умеет он сильно больше

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

     
     
  • 6.28, нах. (?), 15:35, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > ложь. если почитать внимательнее, то он не умеет даже клонировать

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

     
  • 6.36, Аноним (4), 20:13, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > я не ждал тжри года, пока что-то доделают на расте, взял cgit на сишечке и пользуюсь

    cgit, как и все подобные "простые" решения, не умеет Git 2.

     
     
  • 7.40, 12yoexpert (ok), 02:25, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    cgit это вообще-то веб-морда. работать с git на своём серваке можно как угодно
     
     
  • 8.43, Аноним (4), 03:28, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Предлагаю почитать описание cgit и его фич на официальном сайте Для ленивых Эт... текст свёрнут, показать
     
     
  • 9.59, 12yoexpert (ok), 14:14, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    не только через http transport от cgit... текст свёрнут, показать
     
  • 6.37, Аноним (4), 20:20, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > ложь. если почитать внимательнее, то он не умеет даже клонировать

    https://github.com/GitoxideLabs/gitoxide/blob/main/crate-status.md

    Вы о чём вообще говорите-то? Я например про проект gitoxide. А вы, похоже, про командлайновую тулзу для конечных пользователей.

    В проекте gitoxide огромное количество сделанной работы, отображённой галочками в этом документе под каждой библиотекой. Конечная тулза делается на основе библиотек, а не наоборот.

     
     
  • 7.41, 12yoexpert (ok), 02:27, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы о чём вообще говорите-то?

    читай галочки в ридми

     
     
  • 8.44, Аноним (4), 03:34, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Чел, ты угораешь что ли Смотри на реализацию фич библиотек Это то, что реализу... текст свёрнут, показать
     
  • 4.21, Аноним (21), 12:24, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > 9K звёзд, 14K коммитов и 1940 релизов (тысяча девятьсот сорок).
    > но пока что только клонировать умеет, и то не всё

    Кажется они поняли release early, release often весьма буквально. Интересно, а релизы им роботы нарезают, без чанжлога даже? Тогда пусть и пользуются тоже - роботы ;)

     
  • 3.12, Нуину (?), 07:06, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А как же https://github.com/facebook/sapling
     
     
  • 4.15, нах. (?), 10:03, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А как типичная поделках хрустиков (ну или как типичный опенсорс от мордокниги, что, впрочем, одно и то же).

    https://github.com/facebook/sapling/blob/main/eden/mononoke/README.md - даже не компилируется. Но нате на лопате непонятные бинарники with  key areas omitted are:
        Documentation on how to configure.

    Зато cli - прям замечательный. Зачем нужен - не признаются.

    И в таком вот виде - "даже и не компилируется" оно пребывает уже лет ДЕСЯТЬ.

    Отдельно смешно что изначально заявлялось как замена _hg_, а теперь, гляньте-ка - ни одного упоминания hg в ридмишечке, "Git-compatible source control system", ага. (дайте угадаю - вы не найдете в логах того места где оно вдруг стало из hg гитом. Ну а память у хрустоистеричек - девичья.)

    Я боюсь открывать мордокнижкин прожект по переписькиванию пехепе - кто смелый, возьмите длинную палочку и гляньте - а то вдруг там уже s/php/1c/ (и forced push, чтоб замести следы)

     
     
  • 5.16, Аноним (16), 10:26, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Они назвали свой язык Hack, и он уже довольно существенно отличается от PHP. Как drop-in замена PHP уже давно не позиционируется.
     
     
  • 6.17, Аноним (16), 10:29, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    ...и, вообще говоря, выглядит их язык куда лучше, чем нынешний PHP.

    Если в PHP 8.4 добавлены исключительно синтаксический сахар, то в Hack добавлены дженерики, async-await и подобные реально нужные вещи.

     
  • 6.18, нах. (?), 10:50, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    ну вот свою версию меркуриала они назвали соплинг или как-то так - а теперь вон васян с памятью рыбки гуппи внезапно обнаружил что это гит и "всегда был".

    Так что ты зайди, и глянь, осторожненько, широко окно не открывай. Может там уже "существенных отличий" от 1C зато не осталось. (но по прежнему нельзя скомпилировать, конечно же - тоже уже лет десять, наверное)

     
     
  • 7.19, Аноним (16), 11:28, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Они это всё делают для своих внутренних целей, в опенсорс выкладывают скорее для привлечения новых сотрудников - пилить язык программирования или систему контроля версий всяко интереснее, чем формы шлёпать. На их CI компилируется - им этого достаточно.

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

     
     
  • 8.29, нах. (?), 15:41, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    для меня полнейшая загадка зачем они это делают и кого этим надеются завлечь Ка... текст свёрнут, показать
     
  • 5.22, Аноним (22), 12:28, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Отдельно смешно что изначально заявлялось как замена _hg_, а теперь,
    > гляньте-ка - ни одного упоминания hg в ридмишечке, "Git-compatible
    > source control system", ага. (дайте угадаю - вы не найдете в логах
    > того места где оно вдруг стало из hg гитом. Ну а память у
    >  хрустоистеричек - девичья.)

    Баззворд иссяк. Видимо всех необучашек уволили или перевели на гит - проблема и отпала. А HG к тому моменту как раз бесславно сдох по причине "версия питона не та". Скучать о куске тормозного питона от тех кто пытался DVCSом SVN комплетить - очень мало кто будет.

     
     
  • 6.25, User (??), 14:35, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Когда там гит появился? Году в 2004? Выросло поколение, для которого "git был ВСЕГДА" и ничего не то, чтобы "лучше", а хотя бы "другого" они и не видели, так что чоужтам...
     
     
  • 7.27, Аноним (-), 15:18, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Когда там гит появился? Году в 2004? Выросло поколение, для которого "git
    > был ВСЕГДА" и ничего не то, чтобы "лучше", а хотя бы
    > "другого" они и не видели, так что чоужтам...

    Я немного пользовался CVS и SVN - но это тот случай когда я с удовольствием забуду всю эту дрянь повернутую на единственном огромном центральном сервере - как страшный сон.

    Еще были всякие проприератщики типа Bitbaker. Они делом показали почему с проприетарщиками не следует иметь дел в своих воркфлоу. Торвальдс делом покахал как оборзение проприетарщиков лечить правильно. И многие из нас усвоили этот урок. Never again.

     
     
  • 8.30, нах. (?), 15:43, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    но врать научились прям сразу как рот открывают т е ты ничего и не помнил ед... текст свёрнут, показать
     
     
  • 9.47, Аноним (-), 08:44, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Я в те античные времена немного возился с реактосом - и помню какая это боль был... большой текст свёрнут, показать
     
  • 8.31, User (??), 15:47, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, если пользовался так же, как и git ом - по оглавлению , то я и не удивлён, ... текст свёрнут, показать
     
     
  • 9.32, нах. (?), 16:34, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    да, умение автоматически встроить содержимое readme md в веб-версию корневого ка... текст свёрнут, показать
     
     
  • 10.49, Аноним (-), 09:00, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Специалист ожидает - что инструмент который сватается как система контроля верси... текст свёрнут, показать
     
  • 9.48, Аноним (-), 08:50, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Меня там для начала дико бесил - перфоманс перематывания версий С какого-нибудь... большой текст свёрнут, показать
     
     
  • 10.51, User (??), 09:29, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    И где ж ты, пользовавшийся CVS и SVN в них бд -то нашел, а Подскажи пенсионе... текст свёрнут, показать
     
     
  • 11.53, Аноним (-), 10:24, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    По моему какие-то версии свина - пытались тянуть какие-то db-тулсы Но лично мен... большой текст свёрнут, показать
     
  • 8.69, Аноним (69), 05:22, 14/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Как же из тебя прет ободание и преклонение перед Торвальдсом Ещё и урок там как... текст свёрнут, показать
     
  • 3.66, Mike Lee (?), 15:23, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну тем кому порог входа в git слишком высок лучше чем-нибудь другим заняться.
     

  • 1.9, Аноним (9), 03:51, 12/01/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    >В GitHub сборка с упрощённым SHA-1 позволила на 10-13% повысить производительность операций извлечения и клонирования данных.

    Ждём атак против гитхаба с подменой объектов в репозиториях. Напр. лучше всего подменять picklы.

     
     
  • 2.63, Аноним (62), 14:37, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Да-да, подмены объектов в репозиториях через read-only запросы. Мамкин безопасник.
     

  • 1.33, Аноним (33), 17:20, 12/01/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А есть простая альтернатива для мини-проектов? Чисто отслеживать изменения без всех вот этих "свистелок"?
     
     
  • 2.34, Anyone (?), 18:17, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Mercurial (HG).
    Только осторожно, после него вы от гита будете плеваться.
     
     
  • 3.60, Аноним (60), 14:30, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Есть травоядные. Есть плотоядные.

    А есть те кто hg вспоминает. Они любители особого вкуса.

     
  • 2.35, nilsys (?), 19:00, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    можно просто не пользоваться функционалом, который не нужен

    для 90% репозиториев хватает commit, branch, checkout и merge, и ещё push/pull для работы с удаленными серверами

    для оставшихся 10% уже нужны остальные 95% гита

     
  • 2.38, Yandex Man (?), 21:37, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Git итак простой. Сделал ветку, закомитил изменения в ветку, замержил ветку в мастер когда готово, и так для каждого изменения.
     
     
  • 3.39, Нуину (?), 23:56, 12/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Git итак простой. Сделал ветку, закомитил изменения в ветку, замержил ветку в
    > мастер когда готово, и так для каждого изменения.

    А почему тогда у вас в конторе, уважаемый Yandex Man, сделали свою систему контроля версий?

     
     
  • 4.65, Аноним (62), 14:46, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Своя система контроля версий сделана из git и имеет совместимый с ним cli (а какой же ещё?). Сделана она потому что у нас мегарепа, настолько большая что на локальную машину её не то что склонировать, но даже просто зачекаутить долго и тяжело. Поэтому там виртуальная файловая система с удалённым доступом к git хранилищу.
     
     
  • 5.67, Школьник (ok), 19:51, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А зачем вам, если не секрет, мегарепа? Побить на части не получается?
     
  • 3.42, Анониссимус (?), 02:55, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Это только так кажется. Как только потребуется сделать что-то нестандартное, придётся перелопатить гору манов. Или довериться чатгпт. В такие моменты думаю -- уж лучше бы хранил версии просто в папках. Это будет то же самое, что гит, только без мозгопарева гита с его протёкшими абстракциями.
     
     
  • 4.45, Нуину (?), 05:07, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В целом устройство не такое сложное https://www.opennet.me/opennews/art.shtml?num=52355

    > Как только потребуется сделать что-то нестандартное

    Например?

     
     
  • 5.56, Анониссимус (?), 11:46, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Например?

    Из недавнего:
    1) перенести несколько коммитов в другую ветку (случайно не в той ветке сделал)
    2) скопировать несколько файлов из старого коммита

    Делать это приходилось через какие-то дичайшие костыли.

     
     
  • 6.61, Аноним (60), 14:32, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    1. чери пик

    2. чери пик
       убираешь лишнее и
       аменд

     
     
  • 7.68, Аноним (68), 00:52, 14/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    2. скорее checkout, только не ветки а файлов

    git checkout commithash pathname

     
  • 2.46, jj установи да (?), 06:32, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    jj установи да
     
  • 2.50, Аноним (-), 09:08, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > А есть простая альтернатива для мини-проектов? Чисто отслеживать изменения без всех вот
    > этих "свистелок"?

    Fossil можешь попробовать, но без свистелок - понятие относительное. Там всякие вики и проч - но при этом он довольно мелкий.

    Впрочем в сабже никто не заставляет же вон то юзать. Реально вам потребуется 5-10 типовых команд. Остальное это продвинутости и навороты для гуру, то что вы на этот уровень выйдете - еще не факт. А умение git - ценный актив. Это почти везде сейчас - требуется. Зайдите на любой сайт вакансий, прочитайте требования. Отточить этот скилл на именно своих проектах - весьма валидная идея.

     
  • 2.55, freehck (ok), 11:28, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А есть простая альтернатива для мини-проектов?

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

     
  • 2.64, Аноним (62), 14:41, 13/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Что такое 'мини-проект'? Если он выкладывается в паблик с тем чтобы им пользовались другие люди, альтернатив нет, потому что никто не будет ставить уродцев типа фоссилов или пихулей чтобы скачать или законтрибутить в твою поделку. А если проект чисто в стол, делай что хочешь.
     

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



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

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