У чому різниця між git switch і git checkout <branch>

166

Git 2.23 представляє нову команду git switch- після прочитання документів здається майже таким самим, що git checkout <branchname>хтось може пояснити різницю чи варіант використання?

Дві нові команди "git switch" і "git restore" представлені для розділення "перевірка гілки для роботи над просуванням своєї історії" та "перевірка шляхів з індексу та / або дерева-іш для роботи над просуванням поточного історія "з однієї команди" git checkout ".

git git-checkout git-switch

— Бастіан Вентур
джерело

На InfoQ є хороша стаття на цю тему: infoq.com/news/2019/08/git-2-23-switch-restore

— rsenna

Відповіді:

181

Ну, згідно з документацією, на яку ви посилаєтесь, її єдиною метою є розділити та пояснити два різні способи використання git checkout:

git switchтепер можна використовувати для зміни гілок, як git checkout <branchname>це робить
git restoreможе використовуватися для скидання файлів до певних версій, як git checkout --<path_to_file>це робиться

Людей бентежать ці різні способи використання git checkout, як ви можете бачити з багатьох питань, що стосуються git checkoutтут на Stackoverflow. Схоже, розробники Git це врахували.

— ковський
джерело

Це здається гарною зміною. Зробити гілку? git checkoutПереключити гілку? git checkoutОтримати певну версію файлу? git checkoutВидалити зміни до одного файлу? git checkoutЧесно кажучи, мені цікаво, скільки нормального робочого процесу git можна зробити за допомогою різних прапорців git checkout.

— Капітан Мен

Тож зараз ідея, git checkoutяка технічно ні для чого більше не потрібна? Або він все ще використовується для певних речей, таких як перевірка коміту, який не є головою гілки (перехід у режим "від'єднана голова")?

— PieterNuyts

@Mike Як ви можете сказати, що checkout не робить гілок одним реченням після того, як ви кажете, що checkout робить гілки? Не має значення внутрішня робота -bпрапора. Це все ще робить гілку.

— Капітан Ман

@CaptainMan, checkout операція не створює гілки, вона може лише перейти у вже існуючу гілку. -bВаріант для checkout команди внутрішньо виконує , git branchперш ніж він на справді робить перевірку. Це те саме, що і git pullярлик для git fetch+ git merge.

— Mike

Корисна примітка: для тих, хто звик, git checkout -b <branch name>ви можете використати, git switch -c <branch name>щоб отримати той самий ефект

— Xeuron

git checkout це трохи швейцарського армійського ножа, який має кілька не пов’язаних між собою застосувань.

Якщо ви модифікуєте файл, але не здійснили зміни, зміни git checkout <filename>буде змінено ... швидкий і простий спосіб скасувати зміни у файлі. Ви залишаєтеся в тій же галузі.

git checkout <branchname> (як ви вже зазначили) перемикає гілки.

Дві абсолютно різні цілі, які можуть призвести до плутанини, якщо ім'я файлу та ім'я гілки схожі.

Якщо це дві команди, це зрозуміліше.

— СтівТурчин
джерело

Як ви вже згадували, наявність гілки та файлу з однаковим ім’ям викликає заплутаність. Я припускаю, що гілка має пріоритет над файлом, оскільки це часто є більш бажаним? Або як це працює?

— AgentM

@AgentM Так, це правильно. Якщо гілка та файл мають однакові назви, тоді це git checkout <name>робить перевагу гілці замість файлу.

— Картік Сонеджі

switchмає деякі обмеження: на даний момент ви можете перейти з будь-якого коміту на <branch name>, однак неможливо перейти з <branch name> певного коміту зі статусом від'єднаної HEAD . Отже, вам потрібно використовувати git checkout 5efb(де 5efb є прикладом посилання на хеш довільного коміту)

— daGo
джерело

Я б стверджував, що це фактично особливість, а не помилка (обмеження). switchстворюється з єдиною метою зміни гілок, і коли ви це робите, ви хочете бути в ГОЛОВІ цієї гілки. checkout- це більш загальна операція, яка приводить вашу робочу копію у відповідність до будь-якого стану в історії (= коміт). Оскільки будь-яке ім'я гілки є псевдонімом для коміту HEAD цієї гілки, перевірка гілки технічно не відрізняється від перевірки будь-якого іншого коміту.

— Майк,

з -dвами можна:git switch -d 6c13

— Менді Барель