As I told you in the last lesson, quite often, we use
visual diff tools for comparing files. There's so many visual
diff tools out there. The most popular ones are K, diff, and P
for merge, which are cross platform, and winmerge that runs
only on Windows. In this lesson, I'm going to show you how to use
VS code for comparing files. If you want to use a different tool
or a different editor, you have to look up the instructions
yourself. So here in the terminal, first, we have to tell
Git that we want to use VS code as our default default. So we
have to set to configuration settings. So once again, we type
Git config, dash dash global, so the global settings apply to all
of our repositories. Okay. Now, the setting we're going to set
is diff tool. We're going to set that to VS code. So with this
command, we're just giving a name, in this case VS code to
our default default, next minute to tell git, how to launch VS
code. So once again, git config dash dash global here we set
default dot VS code dot cmd. We set this to double quotes
because we're gonna have a space. Now on my machine, I've
added code to my path, so I can run it from any directories. If
this doesn't work on your machine, you have to look up the
instructions yourself, depending on your operating system. So
we're going to launch code with a few arguments. The first one
is dash dash, wait, this tells the terminal window to wait
until we're done with VS code. So until we have compared the
changes and close the VS code instance, the second argument is
dash dash diff. This tells VS code that we want to use it for
diffing or comparing files. Then we have two more arguments,
dollar sign, local in capital, and dollar sign, remote and
capital. These are placeholders for the old and new copies of a
file. Okay, so let's set that. Now. Let's make sure that you
have got this step right. So we're going to run git config
dash dash global dash e as I told you at the beginning of the
course. With this command, we can edit our global
configuration settings in our default editor, which is VS
code. So take a look. So all these things are stored in this
file dot Git config, which is stored in this directory. So we
have the user section, which we said earlier in the course.
Here's the diff section that we just set. In the section, you
have set the tool to VS code. This is just a name. Then we
have diff tool VS code. And here's the command that should
be run for comparing files with VS code. So we have code with
dash dash Wait, then dash dash diff. And now those two
placeholders that I added, for some reason they're lost. So
let's add them real quick. dollar sign, local, and dollar
sign remote. Make sure to get this right. Otherwise things are
not going to work on your machine. Now we're done. So
that's closest we know. Back into terminal, instead of using
the diff command, we're going to use diff tool. This will allow
are a visual diff tool for comparing files. Now if you
don't supply any arguments, we're going to see our unstaged
changes. So this will compare what we have in the working
directory with what we have in the staging area. If you want to
look at our state changes, we supply dash dash sticks exactly
the same way we use the diff command. Okay, so let's look at
the changes we have in our working directory. We have
modified only a single file, that is why we have one out of
one, and that is file one dot j s. So Git is asking if you want
to launch VS code, which is the name that we assigned to our
default dev tool. Let's go ahead and take a look. So here's the
old copy, which is what we have in the staging area. And here's
a new copy, which is what we have in the working directory.
As you can see, we can easily tell that this line has been
replaced with this line, it's much easier to see the changes.
Now the terminal window is waiting for us to close the VS
code instance. So let's close this window. Back to the
terminal. Now let's look at the state changes. So, git diff
tool, dash dash staged, two files have been affected in the
staging area. The first one is file one dot j s, let's look at
the changes. Alright, in this case, the old copy is what we
have in the last command. And the new copy is what we have the
staging area. So these are the changes that are going to go
into next commit, we can easily tell that we have added two
lines here. Now let's close this tab. Back in the terminal, Git
is asking if you want to look at the changes in file to the J s.
In this case, I'm going to ignore that So no, I quite
honestly, we don't use dev tools so much these days. I just
covered it because I want my course to be comprehensive.
These days. Most editors and IDs allow us to view the stage and
unstaged changes as part of our development environment. I will
show you how to do this later in the section.