Switch and Restore on Git
Modern development seems to go hand in hand with git. Almost every project (including some made by universities students) use it. And to my knowledge, it is the most popular form of version control system (VCS).
DISCLAIMER: For those that don't know what git is, Git is a program for controlling versions of (not exclusively) source code. I do not intend to teach git in this article as there is a plethora of tutorials across the internet that would likely do a better job. If you don't know, I recommend reading those first and then come back, as this is still useful (actually, even more, as you have not acquired any biases).
Git is a monster and to this day I still discover something that is possible to do with it. But to the common (and somewhat beginner) developer, just these commands are enough.
You might have noticed but there are two very different reasons (and ways) to use git checkout . And, specially for non-English speaking developers, checkout does not SAY what it DOES (perhaps for those that work/study git internals).
On that note, the team behind Git brought experimental commands to those that find checkout a bit too complex on version 2.23.
The additions in question are git switch and git restore, and meant to help with the separation of checkout operations that change branches from those that change files.
Checkout command
As stated before, checkout does a lot of things. According to its own documentation, what it does is "switch branches and restore working tree files". You'll find some of its most common usage down here:
But what does this have to do with checkout, you ask? Nothing much really. The name comes from pre-git VCS's that had a more natural reason to use it: its akin to Checking-out a book from a library. But with time, git checkout gained more and more power, more and more features, and it deviated from its original meaning.
Switch command
With a better nomenclature that adheres to its functionality and more concise set of feature, git switch, lets users jump to a specified branch and updates the working tree as well as the index to match it (exactly like checkout did). Also, if the branch to jump to does not exists, there is an option to create it (also, exactly like checkout did), but, instead of -b that, it might mean branch, because it calls git branch, switch uses a -c that it is much closer to create.
Restore command
As the switch counterpart (to complete the functionality of checkout), Restore, is meant for restoring paths in the working tree, index content or both. It works almost the same as checkout, but to the beginners, it's the same. Therefore, there is not much to talk about, but show how it would be done using restore:
It is experimental!!
Everything is nice and dandy, but we have a little problem. According to the documentation of both commands (version 2.29 now), these are experimental commands and their behaviours may change.
With that said, I don't think that the behaviour will change that much. Sure, new options may add some functionality. And, perhaps, some current ones may come in a new form as both the git development team and its community comes to a better understanding of the desired usage.
But to common features, like those I've shown previously, are very much likely to not change. So, it is 99.999999% safe to use. And the remaining part is just playing safe.
Conclusion
I believe these commands are promising, because they make the (somewhat intimidating) git interface easier to understand and reason about, and that is a great step towards user experience. And even if the commands are experimental, this is actually the time for users (old and new) to test it and, through feedback, enhance the experience even further. I, for one, intend to abandon my checkout-biased way and enter the new era of switch&restore.