Please wait a little before you start… bashing me.
The CLI
You should totally learn the CLI and it’s still important to know what to do when, for some reason, the GUI you’re using have some problem. Also, that was, clearly clickbait…right?
Living outside the CLI
I use VSCode with Git Lens to the point I have no idea how much of what I’ll be saying here is just the VSCode alone and what is done through Git Lens. But if you’re using VSCode, then you only have to gain to install Git Lens, if you haven't yet.
Another extension worth mentioning is the Conventional Commits, which lets you compose beautiful commit messages and make you remember each part of the commit according to the Conventional Commits specification.
The tool you’ll use
If you’ve skipped, if I say something and you don’t find it in your VSCode, then maybe it’s the lack of having Git Lens installed.
You have a whole tab dedicated to Git.
It shows tracked and untracked files, it shows all repositories if you have multiple in your workspace, and it also shows branches, repositories, stashes… basically everything you need and more.
For using branches
Some people end up missing this, but on the bottom corner:
You can easily sync changes (it already shows you if there’s something incoming or outgoing).
If you don’t have any changes it also makes clear you have changes to push or to pull:
So, no more excuses for “I forgot to push”.
And by clicking the button with the branch name you can easily change branches or create new ones.
For committing
If you've never checked out, you would probably see something like this when you have some changes:
The first thing I recommend is to switch to tree view (it’s the bunch of lines icon above the message input). You should be seeing something like this:
The files with M mean “modified” files.
The files with U mean “untracked” files (new files).
The files with D mean “deleted” files.
You can also check the colors of those letters.
They show you new (green), modified (blue), and deleted (red) files.
And (if you have any kind of lint and other extensions that find it) they also show you if they have warnings (orange) or errors (red).
Working with the changes
When clicking or while hovering you’ll see:
You can jump to the file, discard and stage the changes.
When clicking or hovering the “Changes” or “Staged Changes” line:
You can stage/unstage all of the files, discard all, or even stash them.
Also, when you click it, it opens the changes:
(You can use inline changes if you prefer it in the “…” (three dots) button)
The one feature that makes it worth it
So far, it shows all in a neat way, but all of that you can easily do in the CLI, and some do prefer it that way, but this is the thing that will make you think twice and I dare to say: this actually changes the way to code!
Let’s say you have this:
Lot’s errors, but you have one line working that will work by itself… do you commit the whole file with all the breaking errors, or… what do you do?
Well… you can as easily as two clicks… stage only one line!
Right-click the line:
Then left click on “stage selected ranges” (that could be multiple lines selected):
Now commit only the line that’s working by itself without even having to touch any of the work you don’t want to touch right now.
(Yes, I know it’s possible to do that with CLI, but nowhere near as easy as that!)
Want more?
This could be a bug that is actually a feature… but you don’t even need to have the changes you’re staging saved! Yes. You can stage unsaved changes! 🤯
(As you stage changes, the left panel shows what’s staged. When you discard your changes, it picks that difference.)
I’ve discovered that because I usually force filters of tests “fdescribe/fit” and I had committed those “f”s while still using them. So I just changed the line and staged, and only then I saw I hadn’t even saved it.
So if you need to make little changes to make sure that you can open a commit and it works, you can do them without even saving. Change, stage, undo.
Managing stuff and other things
There are a lot of other things you can do, especially regarding syncing, changing, deleting, and renaming branches, and stashes.
Don’t forget to check the command pallet to see other cool stuff you can do.
My preferred one is to cherry-pick (use the GitLens one for this one).
You can also, on each file, navigate the changes commit by commit.
I probably forgot to mention a lot here… so ask away! And leave yours too!
Cover Photo by Praveen Thirumurugan on Unsplash
For anyone interested:
- Theme: Dracula (Dracula Official)
- Icons: vscode-icons
- Font: VSCode default
Top comments (7)
As much as I understand the ease of use of git lens, I strongly disagree with your title statement. Or, more precisely, I think depending on an IDE for using git is dangerous.
Knowing your way around git in a cli is very important: connecting to a remote server? Writing or debugging a CD pipeline? Needing to do something there is no button for? Or simply wanting to quickly do an operation without having to load a bloated IDE? (yes, vs code is fast at the beginning, but add the 100+ plug-ins you need - according to posts here, and suddenly...)
So my advice is: work with the cli first. It may be painful at first, but will become a second language at some point. Don't give up. Only once you are perfectly fluent with the cli, then switch to lazygit, git lens, or another tool.
Git is a the root of any programming activity, so it should be deeply understood and there is no better way than the cli for this. It also comes in handy in job interviews ;)
PS: coming from a full stack background, there is to me no better interface than a terminal.
Absolutely agree with this answer. Depending on an IDE to do your stuff is probably the worst "decision" you can make.
Also people tend to think that they'll be faster using some GUI, that's because they don't know how to use the CLI properly.
While I agree with most.
I don't think you can commit it line by line, all while possibly editing stuff, even without saving, in between.
You shouldn't do that anyway. Per-line staging is reasonably simple (
git add -p), but the real question is: why would you want to do that in the first place?Normally, you'd want to commit an entire working changeset.
When you have something small and contained... absolutely.
But when you start touching multiple things at once (and it can be as little as fixing a typo).
Then I do prefer on making an atomic commit, even if only changing a single letter.
More than that, multiple times I find myself working a whole feature that I can commit block by block with a more meaningful message than if I were to squash all of them in a single commit.
Totally agree. (Except for making line by line staging, which is so much easier in the IDE)
But for me, more than just being "fast".
I read, edit and refator the code multiple times before even thinking on commiting it.
So, when I go to commit, the "ritual" of going file by file or even line by line and making each commit is another pass through the code that I would not do if I just blaze through it adding everything and using some macro to add, commit and push everything.
In this regard, it's not about speed, but being thoughtful of each step of what you're doing.
ok, let's suppose your set of changes apply to more then 10/40+ repositories and those changes have to be backported to several branches.... Bye!! :) (jejeje)