Минулого тижня був представлений випуск нової версії розподіленої системи управління джерелом Git 2.23. Порівняно з попередньою версією, в цю нову версію було внесено трохи більше 500 змін.
Але між нещодавно введені вдосконалення в цій новій версії, до яких приділяється найбільша увага git switch y git restore, ці - це дві експериментальні команди специфічні який може бути використаний для заміни команди певною мірою git checkout. Для тих, хто не знайомий з git, вам слід знати, що це одна з найпопулярніших, надійних та високоефективних систем управління версіями, яка забезпечує гнучкі нелінійні засоби розробки на основі розгалуження та злиття версій.
Щоб забезпечити цілісність історії та стійкість до змін заднього огляду, для кожного коміту використовується неявний хеш усієї попередньої історії, а окремі розробники комітів та тегів також можуть мати цифровий підпис.
Основні нові можливості git 2.23
У цій новій версії git представлені вищезазначені експериментальні команди "git switch y git restore".
Ці нові команди призначені для розділення функцій «git checkout» пухкі, такі як маніпуляції з гілками (зміна та створення) та відновлення файлів у робочому каталозі («git checkout $ commit - $ filename») Або відразу в зоні постановки («--staging«, Не має аналога в«git checkout«).
git checkout це команда, яка дозволяє, наприклад, змінювати гілки або створювати нові гілки в сховищі.
Якщо користувач хоче відредагувати окремі файли або навіть скинути імена файлів у сховищі на своєму жорсткому диску, щоб вони були схожі на їхні файли, він також може використовувати git checkout. На додаток до цих можливостей, інші дії можна виконувати за допомогою команди git checkout.
Варто зазначити що, на відміну від «git checkout«,«git restore» видаляє невідстежені файли з відновлених каталогів ("–Нет накладання" за замовчуванням).
з git restore, набагато простіше точно визначити, які файли будуть змінюватися, як вони змінюватимуться і де вони змінюватимуться. Насправді, замість використання складної команди git checkout, git restore надає 2 варіанти, щоб вказати, куди йтимуть відновлені зміни.
Отже, якщо ви передасте параметр --worktree (або ви нічого не вказали), зміни будуть внесені до сховища на вашому жорсткому диску. Однак якщо ви передасте параметр --staged, зміни потраплять до індексу. Нарешті, якщо ви передасте обидва параметри, зміни потраплять до двох відповідних місць.
У git 2.23 опція "git merge --quit«, Який, як« –abort », зупиняє процес злиття гілок, але залишає робочий каталог недоторканим. Цей параметр може бути корисним, якщо бажано опублікувати деякі зміни, внесені під час ручного злиття, як окремий коміт.
Команди git clone, git fetch y git push тепер вони враховують наявність комітів у пов'язаних сховищах (альтернативних).
Варіанти «git blame --ignore-rev"Y"--ignore-revs-file»Пропустити коміти, які внесли незначні зміни (наприклад, виправлення форматування);
З іншого боку, ми можемо знайти доповнення опції «git cherry-pick --skip»Пропустити конфліктний компроміс (запам'ятовується аналог послідовностіgit reset y git cherry-pick --continue«)
Станом на цю версію, git log буде враховувати за замовчуванням зміни, внесені поштою, подібно до того, що вже відбувається в git shortlog.
Операція оновлення діаграми commit (core.commitGraph) подана в 2.18 була значно прискорена. Він також пришвидшив git для кожного посилання у випадку використання декількох шаблонів та зменшив кількість дзвінків з auto-gc вgit fetch --multiple".
Конфігурацію додано статус. попередуЗзаду, встановивши опцію «git status - [no-] ahead-behind»Постійно.
«git branch --list»Тепер завжди відображається окрема HEAD на початку списку, незалежно від мови.
Окрім цих удосконалень, ця нова версія Git тепер може використовувати посилання з іншого рішення як частину перевірки підключеного об'єкта що може статися, коли ви клонуєте сховище та вказуєте інший під час клонування або в іншому.
Si ви хочете дізнатися більше про це ви можете проконсультуватися за наступним посиланням.