>> Hi. My name is Rachel McFarlane and
I'm a developer on the Visual Studio Code team.
I'm joined today by my teammate, Alex Ross.
Today, we'd like to talk to you about integrations
between Visual Studio Code and GitHub.
VS Code has the greatest number of contributors
of any open source project on GitHub.
So on our team, we spend an enormous amount of time on GitHub
managing issues and reviewing pull requests.
It's typical for us to get over 100 new issues in a day,
and as of this recording
there are currently 203 open pull requests in our repository.
We're always looking for ways we can improve
our workflows and make them as frictionless as possible.
So I'd like to just jump into
a scenario of working on a GitHub project
and show you some of the things you could do within
VS Code that you might not know about.
Some of these features are built into VS Code itself,
but a lot of what we will show will come from
the GitHub pull requests and issues extension.
This extension has been available for quite some time,
but we've recently been working on adding
a lot of new issues-related functionality.
To begin with, I'm going to install this extension.
Great. Alex and I will work on a new VS Code extension
and I've already built some of the scaffolding for this
in this folder that I have open.
But this is currently code that's just local to my machine.
I'd really like to be able to create a GitHub repository.
If I go to the Source Control view,
I can see that there are two options available to me.
I can either initialize the repository,
meaning just run Git init,
or I can click this new "Publish to GitHub" button
which will actually go and create the repository for me.
I'm asked to provide a name for
my repo, helloworld-demo sounds great.
VS Code will go and
upload everything that I have to this new repository.
I can just confirm that that worked,
and going back to VS Code,
I can see that VS Code ran Git init
and that a new remote has been added
which points to that repository.
Let's get started working on this extension,
and what better way to start than
by immediately adding some technical [inaudible]
I can see here that there's a disposable variable that's unused.
I don't want to handle this now
so I'm just going to add it TODO comment,
but I'd really like to keep myself
accountable and make sure that this gets filed on GitHub.
As soon as I typed "TODO",
a light bulb appeared offering
this "Create GitHub Issue" code action,
and what's really cool is that I can actually
mention GitHub users within any comment within the editor.
So when I type "@", I see
a suggestion list of all mentionable users in the repo,
which in this case, since I'm the only contributor
of the repo we just created,
is just me, and I can actually complete to my username.
If I mouse over this username,
I see a hover with information about this user.
Let's go ahead and create this issue.
I can either just enter the title
or I can use this "Edit Description" button to be
taken to a markdown file where I can enter
both a title and a description.
You'll see that a permalink was generated
for the particular line of code that I was on.
This looks good to me so I'll go ahead and create this issue,
and now we're back in this file.
We can see that a number 1 was inserted into this comment,
and if I mouse over this, I see
a hover telling me information about the issue,
status of it, whether it's open or closed.
I can jump to it on GitHub,
I see the permalink to code
and the first lines of the description.
This will work for any comment within VS Code,
not just one of these TODO comments, so that's really cool.
One other way to create comments from within VS Code is by using
the Create Issue from selection command.
If you didn't want to create a TODO comment,
this is another way to create GitHub issues.
Now that I've actually made this issue,
I'm going to turn it over to Alex
to show how you might handle this issue.
>> I want to see this new extension
that Rachel has been working on
so I'm going to open the Source Control view
and use the "Clone Repository" button.
Clone Repository button is not new
and the command to
clone repositories is also available through the command palette,
but what is new is this code from GitHub.
This is coming from the GitHub pull requests and issues extension.
When I click it, I'm going to be
prompted to authenticate using GitHub.
After a quick redirect
through the GitHub auth page, I'm back to VS Code.
I'm now signed in to VS Code with GitHub
and I have access to prep repositories here now.
I can search for
Rachel's repository and clone it into my repos folder.
You might have noticed that that was not
the usual system safe dialogue,
that was the simple file dialogue.
I like to use it because I find it to be more keyboard-friendly.
Let's open Rachel's repository
and see what she's been up to with this extension.
Now, the first thing I see is this TODO comment in here.
Let's take a look, make sure this is used.
This looks like a pretty straightforward fix
and I would like to make
a pull request for Rachel that fixes this.
First things first, let's get rid of
this red squiggle and install our dependencies.
I'm going to install dependencies using a task.
I like to use tasks because they can
make setup and building simpler.
This task just runs npm install,
and while those install,
let's take a look at the issues that I have assigned to me.
Now, it looks like Rachel actually already
assigned this issue to me
so it's showing up in My Issues view here,
which is also coming from
the GitHub pull request and issues extension.
The queries here are configurable
and there's a default My Issues query
which includes issues assigned to
you in this repository group by milestone,
and then there's also the Created Issues
query that's here by default.
The query syntax is just the usual GitHub search syntax,
so it should look very familiar.
Then we also have variables that you can reference,
things like the currently open repository.
I don't usually use the Created Issues queries.
I'm just going to delete it.
I am ready to start working on this issue,
so I'll use this "Start Working On Issue" action.
This will create a branch
and check it out for me to work on the issue then,
that's a status bar entry.
In the Source Control view,
it populates the commit message with the title of the issue,
fixes, and then the issue number.
This is the commit format that I usually use,
but if your team or project uses
a different commit message format, this is configurable.
The default commit message here is configurable.
One more thing before I dive in and
actually start making some code changes.
I want to see the history of this file to see if there's
anything I should know before I start changing the code.
It looks like there's not a whole lot of history here,
but I can see the dists from each commit.
It's not too surprising that there's not a lot of history yet,
this is a new extension,
but the timeline will show you
the commit history about the currently open file.
Let's fix this issue and use this disposable.
Now that the disposable is used,
this comment is no longer needed.
While I'm here, I also want to add
a new button to this information message.
Now, when the information message says "Hello World" to you,
you can say "Hello back".
I think I'm done fixing the issue.
Now, it's time for me to commit.
I'll go back to the Source Control view here,
stage my changes, and take one more look
before I commit and make sure that
I agree with everything that I've changed here.
Now that I'm looking at it,
I'm reminded that I came here to make a simple bug fix,
not to start adding features.
I think this added button is
not a good thing to include to this commit,
it's not a part of this bug fix.
The built-in Git support is very powerful
and I can select a range and then unstage the selected range.
Now with this, the changes that I care about
being in the commit are still there and
my feature change is now unstaged.
I like this commit message.
I'm just going to delete this and put it on a new line.
With the user suggestions,
you also get them in the commit message [inaudible]
add Rachel's mention back in there.
You also have issue completion suggestions in
the Source Control commit message box as well.
In source files, you get
the issue completion suggestions,
and in markdown files, they're a little special.
If I wanted to have a changelog where I
reference specific issues that have been fixed,
I can use the completion suggestion here
and it will insert a full markdown link
saving you a little bit of copying and pasting.
I'm really ready to commit now
and I commit my bug fix.
The whole point
of coming here was to make a pull request for Rachel.
There are a couple of entry points for me to make a pull request.
There's through the pull requests
view that is in that command palette.
But the fastest way to create a pull request when I'm already
working on an issue is through the status bar entry.
From here, I can create
a pull request or I can create a draft pull request
which is usually used for
changes that are not ready to be merged yet.
Because I'm ready for review
and to have this change merged after Rachel has reviewed it,
I'm going to create a regular pull request.
I do want to merge with master
and I'll use the latest commit message
as the title of the pull request.
Once this pull request is created,
I will be able to interact with it just
like I would be able to on github.com.
Here it is. Looks pretty familiar.
I do want a review from Rachel.
Let me add her, and with that,
I will hand it back to
Rachel so that I can get some feedback on my change.
>> I've just gotten an e-mail notification that
Alex would like my review on pull request,
so I'm going to go actually review
the pull request that she just made.
If I open the pull request view,
I see that there are a number of categories for pull requests
the same way that there are a number of categories for issues.
I can also configure these to whatever search query I would like.
By default, categories we
show match those that are shown on GitHub;
those that are waiting for my review,
those that are assigned to me, and those that are created by me.
In this case, I want to look at
pull requests that are waiting for my review.
I see that Alex has created a new pull request.
If I click on the description,
a web view will be opened that
looks very similar to
the overview page on GitHub for a pull request.
I see the description of the pull requests.
I can add comments to this.
This will show the whole conversation on the pull request.
I can change the labels,
I can change the reviewers,
and of course, I can merge or close the pull request.
One button that doesn't exist on GitHub is this Checkout button.
I'd actually like to test out
Alex's changes and make sure
that everything is still building okay.
When I click this button,
if I didn't already have the remote, for example,
if Alex had been working on a fork,
then VS Code would add the remote and would create
a new branch locally.
Now, I'm actually on this Alex issue one branch
which has all of her changes, and so I can just
immediately test that everything is building.
Let's run the npm watch task.
If I open the terminal, I can see that everything
compiled without any errors, so that's great.
Going back to the Pull Request view,
I can see that as soon as I checked out this pull request,
a new view was added.
This is showing me content-specific
to the pull request that's currently checked out.
From here, I can see a list of all the files that were changed,
and by clicking on one of these,
I get a diff view of all the changes.
I really like to use a unified view
instead of the default split view.
If you want to change this, you can use
the Toggle inline view option under this triple dot menu here.
You'll notice that there's a new white bar
that's been added to some of these lines.
This indicates regions on which I can comment.
Now, I can actually just directly leave comments on code without
leaving my editor. This looks good to me,
so I just want to tell Alex that this is great.
I can either create a comment
immediately or I can actually start a whole review.
In this case, I'm going to start a review.
You'll see that as soon as I added a comment,
a diamond decoration was shown on this file.
So I can easily see which files have some comment activity.
Additionally, when I checked out the pull request,
a new comments view was added to the panel.
From here, I can also get an overview of all comments on
the pull request and quickly jump to them.
So if I were, for example,
addressing feedback on a pull request,
I might want to be able to jump through
my comments and make sure that
I address all the feedback in that way.
The other item under this tree is commits.
In this case, I can see that Alex has only
made one commit in this pull request
and I can see all the diffs for that commit.
This change is pretty simple,
so I feel good about it and I
want to go actually submit my review.
If I go back to this overview page,
I see all of my pending comments and I
can leave a summary comment for the review.
I can either just submit the whole review, or
leave and approve, or request changes review.
In this case, I will actually go ahead and approve this.
Since this is a simple change,
I want to go and actually just merge this pull request.
You can see I can choose whatever merge method I
want and I could
actually type more of a commit message if I'd like to.
So the merge worked and I can actually now delete my branch.
You'll see that I have the option to not
only delete the remote branch
but also delete the local branch that
was created when I checked out the pull request.
I want to clean up both of those things.
Now, I've been put back on the master branch and I can see
that the new commit was added to master.
So I was able to successfully review a pull request
without context switching between my editor and GitHub.
I was also able to easily check out Alex's changes
and validate them locally by just clicking a button.
Now, I'll turn it back to Alex for some closing remarks.
>> Thanks for accepting my PR, Rachel.
We have several resources if you want to try
out GitHub integration in VS code.
There's a blog post, a new documentation page,
and you can always install
the GitHub pull request and issues extension and dive in.
If you do, we'd love to hear your feedback over
in the GitHub pull request and issues repository.
You can get a list of links to
all these resources and more at theurlist.com/vscode-github.
[MUSIC]