Навіщо з'явилися git switch і git restore, якщо є git checkout?

git checkout історично робить дві принципово різні речі:

git checkout feature        # перемкнути гілку
git checkout -- config.php  # відкинути зміни у файлі (безповоротно!)

Одна команда і для безпечної операції, і для руйнівної. git checkout name перемкне гілку, якщо гілка name існує, а якщо ні, але є такий файл - мовчки перезапише файл. Саме через це в Git 2.23 з'явилися дві вузькі команди.

git switch - лише гілки:

git switch main
git switch -c feature/export        # створити й перемкнутися
git switch -c fix origin/fix        # нова локальна гілка від віддаленої
git switch -                        # повернутися на попередню гілку
git switch --detach v2.4.0          # явно перейти в detached HEAD

git restore - лише файли:

git restore config.php                    # відкинути зміни в робочому каталозі
git restore --staged config.php           # прибрати з індексу, зміни лишаються
git restore --source=HEAD~3 config.php    # взяти версію файлу з іншого коміту
git restore --staged --worktree .         # повністю повернути все до HEAD

Відповідність старих і нових команд:

Чому це важливо:

• намір явний: switch ніколи не чіпає незакомічені зміни у файлах без потреби, а restore ніколи не перемикає гілку;
• detached HEAD не трапляється випадково: git switch v2.4.0 відмовиться працювати з тегом без --detach, тоді як checkout мовчки перейде в detached HEAD;
• git status сам підказує нові команди («use git restore...»).

git checkout нікуди не дівся і працює, як раніше, - у скриптах і старих інструкціях він зустрічатиметься ще довго. Але для щоденної роботи switch і restore безпечніші.

Обережно: git restore файл так само безповоротно відкидає незакомічені зміни, як і checkout --. Їх немає ні в reflog, ні в stash.

Докладніше в документації: git switch