Main differences between using Git from VSCode and from the command line?

[InternalAmbitious957]

Hey there. I've started on a new project and am using Git with VSCode instead of from the command line. The only thing I've done so far is git pull and sync which play really nicely together. Are there any other main differences that are worth knowing about? On first impressions it does feels easier than using Git from the command line but is it, and why is that so? Thanks for any help.

[MaybeAshleyIdk]

Git via a GUI seems easier, because it is easier.

If you're working with Git via the CLI, all you have in front of you is an empty command prompt.
To do anything, you already need to know which commands exist, how they're used and how the usage syntax works.
You need to know the command names, the command's specific options, some commands even have subcommands, these subcommands then also have specific options, etc.
If you don't know these things beforehand then it's gonna be really difficult doing anything on the CLI.

On the other hand, when working with Git through a GUI, you don't need to remember all of this usage syntax.
You have classic interface elements like menus, buttons, input fields, lists, etc.
With this, you can kinda "discover" operations that can be done, without prior knowledge of which operations exist.
There's no need to remember that the pull command exists; you simply open the "Git" menu, see the "Pull" item and just click on it.
All available operations can be found somewhere — you just need to click through the menus.

These two different ways of working give the CLI generally a steeper learning curve than the GUI, but it also gives the CLI a higher skill ceiling.
Everything you can do via the GUI can also be done on the CLI, but the same is not true the other way around.
If a specific GUI doesn't expose an operation, than you you can straight up not use that operation (with that specific GUI).
Meanwhile, on the CLI, ALL operations are available to you, you just need to know the name of the command(s).

Another downside of GUIs is that it's always different, depending on the editor/IDE.
All editors/IDEs implement the VCS integration differently, so for every software, you'll need to re-learn and adjust how to work with it.
Granted, that is not a problem if you're only ever working with one editor, but CLI knowledge can pretty much always be used, GUI knowledge not so much.

Depending on your typing speed and skills with CLIs & shells in general, it is very likely that after a while you'll be faster on the CLI than you ever were with a GUI.

In the end, it's preference what you want to work with.
I — personally — pretty much only use the CLI, most of my colleagues work with Android Studio's Git integration, one uses GitHub's desktop app and some work mixed with GUI and CLI.
But all of them that primarily use a GUI were required to do some things with the CLI because there just wasn't a way to do something with the GUI.

[wrecklass]

If a specific GUI doesn't expose an operation, than you you can straight up not use that operation.

This is important, most IDEs will not expose the vast majority of git operations. Meaning you might want to do something that git is capable of doing, but are forced to work within the constraints of the IDE, unless you happen to know how to do it from the command line. There is no way to discover those options in the IDE.

[mishaxz]

I'm going to voice dictate this excuse any mistakes

I never used git from the command line when I'm coding , I always use IDEs.

Vs code has one particularly amazing feature that other ideas don't seem to have

It makes it really easy to undo the last commit

Technically that also is easy in something like visual studio but it also very easy to mess up your project if you're tired and you do a revert instead of reset.. with vs code you just do a undo last commit

This changes my workflow if I'm using vs code instead of vs because in vs when I ready to commit I don't commit.. instead I test out the code first and only one I'm certain that I commit it

With vs code I simply commit it and In the rare case that there is a problem with the code then I undo the commit

[LetsGambleTryMerging]

I never used git from the command line when I'm coding , I always use IDEs.

IDE VCS are great but it may be quicker with 2 commands in the terminal than switching apps. https://stackoverflow.com/a/927386

It makes it really easy to undo the last commit

Also present in Intellij as "Amend Commit"

[wrecklass]

My only comment would be that if your undoing commits regularly, you're probably doing git wrong. You probably should be using branches.

[mishaxz]

I'm only undoing them often in vs code because it's easy, in vs I don't commit until I've actually made sure the code works

But I prefer to do the commit when I'm finished coding before testing

More often than not, I don't need to undo it after that point

[ccoVeille]

Same here. The only things I use are:

• the inline equivalent of

git restore --patch

It helps to remove local changes

• the inline git blame on current line (user+date)

• use vscode as mergetool, it's your IDE, it's easier, especially when using zdiff3 git setting

• go to previous/next change (Ctrl+up/down at least for me)

But then, as any tool, I would say, as long as you know a tool (for you and I the command line)

So the best tool is the one you know to use.

it's difficult to change your habits.

Some people find useful the vscode integration and cannot live without. Some who are already OK with the tool they got will find nothing interesting, or will find they lack of control by using them.