Git with Visual Studio Code | Alexandru Dan | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Git with Visual Studio Code

teacher avatar Alexandru Dan

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

10 Lessons (44m)
    • 1. Class introduction

    • 2. Installing Git

    • 3. Basic Git commands

    • 4. The GitHub interface

    • 5. Git in Visual Studio Code

    • 6. Git commit

    • 7. Git branches

    • 8. Handling commit conflicts

    • 9. Git lens

    • 10. Markdown

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class

Do you want to get stared quickly to use Git, right inside your favorite IDE, Visual Studio Code?

Then you are at the right place!

Welcome to my Git with Visual Studio Code course, where you will learn everything you need in order to keep track of your awesome projects!

Here you will learn only what you need, no extra content, because time is precious!

Meet Your Teacher

Hello, I'm Alexandru.

See full profile

Class Ratings

Expectations Met?
  • Exceeded!
  • Yes
  • Somewhat
  • Not really
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


1. Class introduction: Hi, thanks for joining this presentation. I'm Alex and I welcome you to my good with Visual Studio code Crash Course. What can we expect from this course? We will briefly see how you can install Git for four different operating systems. We will touch some basic commands, but most importantly, you will see how you can handle get inside your favorite IDE Visual Studio Code. We will touch some basic Git commands like in it, commit branch, push, pull. But we will also touch some more advanced topics like handling commit conflicts and merging branches. And we will do this, all of these inside your favorite IDE Visual Studio Code. This course is designed to give you exactly what you need quickly because your time is important. So of course, if this is the case, don't expect that after this course, you will know everything about good, but expect to be able to track your coding, work nicely, direct, directly in your ID. So this being said, if you liked this presentation, please check the course curriculum. And if we like them, less go in class. 2. Installing Git: In this lecture, we will install Git. For this hour, go to my browser and search for Git installed. I will open this website, Git And here I have different options for different operating systems. I will go for the one on Windows, and this will lead me to a download page. I will download my executable and open it. And from now, just follow the steps. And with this, I can install it. And it will install when there's installation is finished or I need to do to check if everything is okay. I will go to my command prompt and type get minus, minus version. And we should see a version which means that we have successfully installed Git on Windows. Let's switch to Linux. Of course, all we need to do here is make a sudo apt install Git, and that's it. After this is finished, I need to do the same check for the version sourcing and get minus-minus version. Again, I get the good version. So it means that it is successfully installed. And the same can be said for installing it on a Mac. Instead of downloading the package for Windows, you can download the package for a Mac and install it using the installer. 3. Basic Git commands: In this lecture, we will learn some basic Git commands. And this will be an, a typical lecture because we won't use any VS Code features. But in order to understand what's happening behind the scene, behind the scenes, you need to know a little about some good commands. Let's get started. I will create a new folder in which we will practice some good. So I will call it good underscore practice. And I will open a terminal inside it. And the first command that we will use is git status. And this will show us what is the status of our source control inside this folder. Okay, we receive a message which says that this is not a Git repository. This is okay because this is not a good repository. So let's make this a Git repository with the command git init. This will create, this will make our folder a Git repository. And now if we inspect our folder, you will see that it will create a hidden folder with called dot. And this will contain all the information about good regarding this folder. Going back. Now if we go to again get status, we will see that we have a branch master. We don't have any commit. Let's create a file in our, in our folder of plain, simple, plain text files. Obviously initial. I will put simple text here, save it. And now we have one initial file here. Let's add these two Source Control. For this, I will select the command git add and with a dot, which means that it will add all the new files which it will fall into, which it will find in our folder. If I now select and git status, it will say that we have a new file which is ready to be committed and less committed. This with the command did commit minus M, which stands for Message. And we will pass here a string containing a message, which explains what we are doing in this commit. So we'll call it first commit. All right, Now if we do git status again, again it says nothing to commit. And now we want to push everything to a remote repository. And for this, we do it with the command git push. But of course we get the fatal because it says no configured Bush destination. And for these we need a repository, a remote repository to work with good. And in this case, we talk about GitHub. This is GitHub. It's a remote repository which we will use for this project. It is free. It is, it works very well. And in the next lecture, we will explore its functionality. 4. The GitHub interface: In this lecture, we will explore and use the GitHub repository for this IM at Here you have the option to sign in or sign up. If you don't have an account, you can simply sign up. You can create a username and an email address and the password. I will sign in with my credentials for this. Let's take where we ended in the previous lecture and create a remote for our good practice project. And for this we need to initialize a new repository. So I will go to our repeals repository's view here. Here I can select new and it is important to give it the same name as you gave to this, to this folder. So I will call our new repository good practice. It will be a public. If you want a private repository, you need to pay. No problem, but public is also fine. I will create this repository and now I have information about it. Very important is this URL, this is the URL of our repository. I will copy it with this button and go back to our terminal inside our good practice project. Here I will call the command git, remote, add, origin and our URL from our repository. And now we can push finally, so I will say git push origin master. For this, I need to provide my credentials. All right, and now if I refresh this page, you will see that we have our initial tech, initial file with our commit message, and I can even open it and see its contents. Let's explore a little the GitHub interface. At this moment, we have here our username and now the name of our remote repository. And as you can see, there are, this is code issues, poor requests. Let's explore a bigger repository. Like for example, the others, SDK. The Amazon Web Service says SDK. And here we can find the repository for RVs, SDK for JavaScript. And here as you can see, we see all the code because it's a public. Here we can see the commits, the branches. Here we see, we can see issues. They are even bogs or feature requests or problems regarding this project. And one more important good command before finishing this lecture is the clone command. And for this, I will select this button here, Clone or download to get the URL of this project, the Ava's SDK. I will copy it and go back to our File Explorer. I will open a new terminal here. And I will use the command git clone. And this will take this project from GitHub directly to my computer. It was a big project, but it's finished. Now I can simply change the directory to this R versus decay. And I can open it directly in VS Code with the command called space dot. And here we can explore everything about this repository, right from GitHub directly into VS Code. Now that we know a thing or two about Git and GitHub. Github, we can start using them with VS Code. 5. Git in Visual Studio Code: Let's start to use Git inside VS Code. For this, we will need any project that we worked until now. I will work on the work on the backend project. We, it will be available as a resource for this lecture. You can use any project you want. We'll open a terminal here and the launch VS code here. And I will, for this our clothes, our files doesn't really matter. I will go to the source control dab here. Notice it says no source control providers registered for this. I will press the plus. But before doing this, Let's check what is happening here in our terminal, the output view and the get view. And as you can see, it already checked for if our there are any source control providers and it said it received a fatal not a Git repository. Let's clear this out and select the plus sign. Of course, we want to initialize good in this project. And as you can see, it will call a git init command. That means that it initialized get in our project and it added the good hidden folders. Also, as you can see, it prepared our changes to be committed. All of them. Now, haven't you? Here, which stands for untracked, we can add one-by-one and prepare them for being committed. Or I can just select the changes, breast applause, and I will stage all the changes. Then I will just add a commit message. Of course, this is the initial commit, so I'll say initial commit. And press commit. This button here, this will come it. Now, if I want to add our files to a remote repository, we usually do this with the Bush command. Of course we will get an error because it says Your Repositories has no remotes configured to push too. So let's configure a remote. And for this we need a remote. I will configure it inside the GitHub and our create a simple repository with the name of our project, which is back-end. So I'll go to might get harbor page to my repositories. I will create a new one and I will give it the exact name and I will call it back. And all right, it's okay. I will create this repository. And what it's important for us at this point is the URL of our repository. I will copy it with this button here. And I will call the command palette and call the command git add remote. We need a remote name, and usually the remote name is called origin. I'll press Enter and a remote URL, which in our case is the URL of the repository we just created. Presenter. Ok, it linked our remote repository to our local repository. Now we can push. And for the initial push, it will say that the, the branch master has no upstream branch. We will create this branch, we will publish it. And now we need to provide our credentials. So I will provide my GitHub credentials, the username, and a password. All right, and it pushed it. Let's check it on our repository. And if I refresh the page, this is great. I see my changes right here. This is great to initialized. We initialized, good. Inside VS code, we will see what we can do with VS Code in the next lectures. 6. Git commit: So we have our project under source control from good. Now, if I go to my file explorer and start modifying files, as soon as I modify them, they will appear in our view. For example, if I just add a comment in our constructor, I have this comment here. Now my file will appear as changed here. Let's modify another file. Let's now modified version inside our package Jason. And of course, our, our file now again will appear as modified. And as soon as I click it inside the good view, the source control view, it will open it in a diff view, which means that it will show me on the left it's old version and underwrite the new version with my modification Lucene for my other file. I can, again, of course, very simple. I can just write here. I'll say update version. A very good practice is to keep your commits as small as possible, which means that you don't start to change all the files, change all your methods, all your dependencies, and then commit. It is usually a very good practice to make a smallest possible commits. I will go to our source control. I will stage my changes and I will commit them. Again if I am making some, some, some changes which I don't like and I don't want to lose diamond to revert everything. I can go back to my source control view. And instead of staging good for commit, I can discard my changes. And these will fix my file. And it will be just like before when everything was okay. But there's one important problem with my project currently. I don't have our node modules. And for this I will go to my terminal and call LPN install. This added the node modules folder to my project. And this folder is a massive, huge folder. And now if I go to my source control, I can click the Refresh button. If I don't see any changes, these sometimes doesn't work. And if I click the Refresh in this moment, it will give me a big warning. And it will say that my current repository has too many active changes. And it will ask me to add my node modules to get ignore. We just h, which is very important. Of course, the third thing you need to do after you install our node modules is to make sure that they are ignored by good. Otherwise, good will work very hard. This command will create a simple file here. Every repository needs this file, the gitignore file, and it will add our node modules folder to it. And notice that this new folder here doesn't appear as modified in source control because it is ignored. I can just also commit this change. At Git, ignore stage it committed and push it, and provide my credentials. Let's see if everything is here. Yes, now I have the gitignore file. In the next lecture, we will work with branches. 7. Git branches: In this lecture, we will work with branches and I'm currently in my repository view from GitHub. And here I have the option to create a new branch. Now I'm on the branch master and I can create a new branch like this. And branches are very useful when you want to extend your functionality and work on your own outside of your team, of your colleagues. And also they are very useful to isolate parts of your code, features, bug fixes, or other important functionality. Let's give it a name to our new branch. And I will call it feature because it's a feature branch. And you will see some feature. I would create this branch and didn't notice it says Create Branch from master, which means that it will take the current state of our master branch, Greater new branch with this name. Now we have it, and now we can go back to VS code. Notice that also we have the, we can see on which branch we are currently in, right here on the status bar, on the left, we are on the master branch. If I press it, I get a pop-up with the list of branches. And notice that our feature branch is not here. That is because we didn't notified VS Code about our new branch. Let's do this. And I can call the synchronize button. But again, this will not work. So I will call a good pool. And notice that good Pull knows that there is a new branch here, it, and it knows its name feature some branches. And if I go again to our Master view, now I can see it here. And if I click on it, we will change to this branch. This view is very useful and important. You always know on which branch you are, what you are working. It is frustrating when you work on a branch and you thought you were on another branch. Let's add some changes on this branch and let's just change the ReadMe. And we say, did a new use less feature. And we will increase the version in package Jason. And let's add something in our or also let's add something in our data service class at the end. In the sort by position method, it doesn't really matter what you do. Now, I will just add again a comment and then we'll call it feature Comment. Save this. And they appear in our changes view. How will I will commit them? I will stage them and commit them. You can give whatever comment you like. I will commit this and notice as soon as I commit, the view here will change. This means that there are 0 incoming changes and we have our one incoming commit which is not pooled. Let's press this. And of course I need to provide my credentials. If you are on windows, you don't have to do this anytime or write. Our changes are here and as you can see, they are in our sum feature. But let's say that we are working and our bus very, very vast comes at us and says that there is a critical bug in our project and we need to fix it. And let's switch our branch to the master branch. Let's say that we are not careful and we are working on the master branch to fix our bug. Notice that on this branch our comment is gone because it is not present on this branch. And let's say that the change was also here in the sort by position method. And here I will add fix critical problem. I will save these. I will also add a comment in the ReadMe and also increase the version in package Jason. Notice that it is the same as we did for our feature. Notice that we are on the master branch and we figure out, hey, I can just commit directly to the master branch. I need first a separate branch in which the new change needs to be tested. And there is a very easy way we can make, we can create a new branch with our local changes. I will just call git checkout minus b and let's call this branch fix, search slash critical. Fix. This. We'll create this branch with our, our, our files here. And now I can safely committed these changes to our critical fix branch. I will add a commit message. Commit this. And if I want to push it, it will say that the branch has no opposite branch, no problem, we can publish it. Now, both our brain, our branches are also in our remote repository. Of course, we affected the same files and if we want to merge the changes on the master branch, we will have conflicts and we will see how to handle conflicts in the next lecture. 8. Handling commit conflicts: In this lecture, we will handle conflicts between our commits. So we have our two branches, one with our critical fix and one with the feature. I mean, in our repository, I will click this compare and pull request button. This will create a pull request and it says a bottom March, I will equate this pull request. And now it says that this branch has no conflicts with the base branch and I can merge this pull request. This will take the changes from our critical fix into our master branch. Now, if we go back to our repository, it says that we have still this new branch, the feature 1. Let's compare and pull request. Great, this, I will create this pull request. And this says that can't automatically merge. And it says that this branch has conflicts. This, that must be resolved. We will, we will fix them. We can even do it from inside GitHub, but let's do it from, from VS code. So let's change the branch to our feature branch. I will clear the terminal. And the way to fix conflicts on good, the best way is to take the current changes that exist on the master branch and integrate them into our feature branch. And then we will not have conflicts. For this IE, I am, I will use some part of the terminal and some part in VS Code. And our first start by checking out the master branch. Because currently the master branch is modified and we need to notice VSCode about this. We will do a git pull. And this will take the changes with the journal we just did. Now we will check out our feature branch. And we need to provide the exact name. So this is called feature, some feature. All right, and now we will say that hey, I want to take the master branch and merge it first into my feature branch. Souls call git, merge master. And here it says, we will get the warnings here that we have conflicts. These conflicts will also appear on our source control view. I can go to our read me file and here appears with a C, which means that it stands for conflicts. And here we see that we have the incoming change and current change. I can either accept both changes, accept the incoming one or the current one. This is the ReadMe, so I can accept both changes. I will then stage this change. And this also the same problem is in our Data Service file, which we both modified. This time, I can accept both changes and this one looks okay. I can still have my feature comments and my fixed critical Coleman. I'll save these all. I will also stage does change. Yeah, this also needs to be done. Vscode some time has problem merging, handling conflicts. That's why I tried to use the common line interface from good. Now that we have our staged changes, I can also add a commit message here, and I will say merged master into some feature branch, commits this, push it. And if we now go back to our GitHub view, we can see that. We can see that we have a second commit which said merged master into some feature branch. And notice that we have no longer a commit conflict. We can also merge this pull request. And now if we go back to our repository now on the master branch, when we have the changes from the, from the critical fix branch and also from the feature branch, even if they were both on the same file. This is the way we can treat conflicts with VS Code and good. 9. Git lens: In this lecture, we will install the good lens extension, which will help us a lot visualize the history of our project. So I will go to the Extension view and search for good lens. And this is the extension. It is very powerful and it has great reviews. I will install it. And as always with all the extensions in VS Code, when we install them, we are getting a webcam view which explain this, how to use this extension. I will learn how will let you read this introduction file? Let's now explore this view. I will close this and go back to our view. And this extension added a new button in our status bar, the good lens view. Let's first view the repositories. And as you can see, we have the back-end project, we have the current branch, we have the history of our current branch. And as you can see here, we see all the, all our commits, all that happened with our commits. Let us open a file. And here, as you can see, we can see what happened in this commit and also what was changed along with this commit. This is a great view and the repository's view. Let's go back to, let's now switch to the file history view. And if we have a file open, Let's open a file. Let's say we open the Data Service. And if we go back to our peatlands extension, we can see all the commits that affected this file. We can see this commit. We can see this commit and we can see what happened here. And as we select them, we see exactly what happened. We can even see the line history. And as you can see, if we have a selected line, it will tell us in which commit it was last edited. This is, this is great. We can even using this extension compare branches. So if I will change all this, now we are in the Compare View and here we can compare even changes. I will select two branches. I will select the master branch and select the sum feature branch. And we can see what is changed between them, what differences are between them, and what commits are between them. This is great. This helps us a lot to deal with our code history. Another great feature of this extension is that we, if we open now a file, any file, and if we select a line, as you can see, it's directly tells us in our editor who did what. In this case, it is myself. When three hours ago and we see the commit ID, initial commit, we see what happened and who did this file, any file. This is very useful when you want to know what happened and who did what in what, in one particular file. Let me show you how a more complex project looks like when exploring it with Midlands. And for this hour we'll go to our R, this SDK JS that we took out a few lectures ago. If you didn't do, you can checkout from Chiquita, out from GitHub. This can be done, this can be done very easy if you go to GitHub and search for others as decay. And searching all GitHub. We can find the R versus decay in JavaScript in case you missed this explanation. And anywhere you can open a terminal and do git clone and your repository. This is the one. I already have it here, so I will not clone it again because it will give me a conflict. It will say our already have this project here. So I will open VS code inside here. And now if I'm in this view and go back to the Midlands view, you will see that the history view and the branches view and the Compare view, it's much, much greater. And see if I just select one file at just random one file and select it, It's file history. I can even see who did what and when. This is the beauty of working with Git Hub and with the public repositories, with the public source code. 10. Markdown: So if we navigate through GitHub and we look for example, at the code from VS Code, and we scroll down in GitHub, we see that it has a very nice Readme file, which show, which looks great and explains us what this program does. The same for other projects on GitHub. There, there is their code and at the end we have a README file, which briefly a nicely explains what this project does. But for our project on GitHub, we see almost nothing. The, for this, Let's create in this lecture a nice Readme file for our back-end project. For this, we will use what is called a markdown language, which is used to nicely format text documents. So let's go to our backend project in Visual Studio Code. And if we open our README dot RMD file, it will look like this. The nice feature about VS Code is that we can right-click on a dot md file and we can open its preview. Notice that we don't have this option for other file types. But for a ReadMe, we can also open It's preview. And we can take the preview and put it on the side, make this smaller, and edit the file. And in real time we can see how it will look. So let's start editing our readme file, and let's start with a description of our project. And here I will type the description. And notice this, notice these DSs here. The R stands for headings. And so if we put one here, it will look big and nice. Here on the preview, we have our description of our project. We can add now a title, and we do this with two DSs. And we will call this part setup. Here. I will show how this can be set up. I will say that only that this project requires and BAM and Node.js installed. Let's add another sub section for the build. I'll call it build project. And first of all, we need to install TypeScript. And we can specify code with backticks. And notice how it will look if we put it like this. This is especially made for code. Let's add the other steps for installing and Px and for running npm install. This is starting to take a nice shape. Now we need to launch the server. So we will add a new section. Again, we will add to, first of all, when we will add the commands that we need to run in order to launch our server is this one, n px dx note. And then we also need to check this. So I will say check localhost. And to make this a URL, I will put this in square brackets and add the URL. And as you can see, this will only add a link for our text here. And now let's add a new section with the services that our backend provides. And for this, we can create a table. And tables are very easy to create in Markdown language, we only need the straight lines. And here we will say Position and URL. And yeah, now VS code doesn't know that we want a table, but if we add a new line here, and if we add dashes, now, it will know that we want a table. So our only paste this table. And you will see how it looks. This is starting to look very nice. I will save all this. And now if we will only look at this preview, we will see that we have a nice description for our project. One important note, VS Code makes extensive use of markdown language. If we go to the release notes, this is mostly red wrote in Markdown. Also, if we go to settings, for example and compare them, you will see that the settings menus look very similar to our README file. Is this a coincidence? I think not. Now, if we commit our changes and go back to GitHub, I will refresh the page. We were on. Some feature branch. No problem. I will create a pull request. Merge it. And now our project looks like this, also on GitHub. Github. And someone else who takes a look at our project will have a much better understanding of what our backend thus.