How to stage changes in Visual Studio in separate files – 068

One of the reasons Git is pretty awesome is its ability to stage changes. I only recently discovered why it is so awesome to stage changes just a couple of months ago. But then again, I was using Ctrl+C, Ctrl+V as my VCS until 2 years ago.

I get ahead of myself all the time and I’ll make several updates at once and then my commit is no longer scope to one functional unit of change. For example, in my Hello World example, let’s say I wanted to make the following changes:

Add a ReadLine() so I have to press Enter to dismiss the console window
Add a new class that contains the actual “Hello World” string to be used – just trivial example to demonstrate making changes to a separate file.

And at this point I realize, “oh no! I forgot to commit part 1.” So now my commits become larger than I want.

What you can do is stage the commit for Part 1, e.g. in Team Explorer – Changes select the file you want to stage, and right-click and click Stage

Now you’ll see two sections in Team Explorer. Your staged changes and your working directory.

Now you’ll see that the Commit All button has changed to a Commit Staged button.

To confirm what is happening, open the command prompt, and run git status. You’ll see that you’ve essentially did a git add Program.cs but via Team Explorer.

Finish the commit by clicking the Commit Staged button.

Now finish part 2 by committing the newly added strings class (and changes to the corresponding .csproj file)

And now if you view the log in Visual Studio – from status bar(!!) click the up arrow,

You’ll see the history with the last two commits

and the command line will confirm, using git log

Now you’ll see that what would have been originally one big commit is now two separate commits thanks to staging.

How to make quick edits in the diff view in Visual Studio – 067

I always assumed that if you’re diff’ing the working directory against the last commit (i.e. Compare with Unmodified), both sides of the diff would be read-only. Turns out, only the last commit (left-hand side) is read-only.

For example, suppose you’ve made some quick edits in Program.cs (see yesterday’s tip), and you’ve opened the diff in the Editor by right-clicking and clicking Compare with Unmodified, you can still make edits on the right-hand side.

In this example, I’ve added a Console.ReadLine(), as anyone who has ever created a throwaway console app knows why. (I thought at one point in VS 20 year history if you switched from debug to release, the console app persisted until you closed it, but it looks like that’s no longer the case)

As soon as you hit save, you can confirm via the command line that Visual Studio is being honest that you can edit changes on this right-hand side.

How to use the GitHub tool window to make changes to a Pull Request from a contributor in Visual Studio – 066

We recently launched support for what we call “Maintainer Workflows.” You’ve got an open source project and you’re receiving pull requests. Suppose you want the contributor to make some changes. You can leave comments in the Pull Request asking them to make whatever adjustments, e.g. adding a Console.Read(); in a Console Application project. But what if they don’t respond in a timely manner or never respond at all? Now within Visual Studio you can pull down those changes, review them, make modifications, commit and push back up to GitHub, all within the GitHub tool window!

(P.S. the Pull Request contributor needs to create the Pull Request by keeping the “allow edits from maintainers” checkbox checked by default. see more at bottom of post).

Continuing from yesterday’s tip, let’s say you’ve reviewed the diff for the PR but you want to make one addition.

1. You can click on the Checkout to <pr/pr-title> link button to checkout the branch.

Clicking on the checkout… link indicates whether the checkout was successful. If not, it’ll tell you to go to Team Explorer – Changes to see what you have uncommited or unstashed.

If you want to verify what state you are in, you can go to Team Explorer – Branches to confirm you’ve checked out a PR branch. Hovering over gives you additional information. You can also view in the VS status bar.

2. Open the solution (if not already opened from Team Explorer – Home – Solutions) and then open the file you wish to modify.

In this example, I want to add a Console.Read() under the Console.WriteLine() that came from the Pull Request.

Don’t forget to save and test your changes! // This is a note for myself 🙂

3. Go to Team Explorer – Changes and make your commit(s) to the branch

4. Push your changes back up to GitHub from the Team Explorer – Sync page

And you should see a success message.

(We’ll cover more about Syncs in VS in a few weeks.)

If you go to GitHub.com to review the Pull Request, you’ll see that there’s been a new commit.

Recap

Let’s take a minute to review what’s going on here. Remember a Pull Request is the start of a conversation. The actual code for the Pull Request sits on a branch that can be updated at anytime, hence why I say a pull request is the “start” of a conversation. In the past, this branch would be updatable by the person who created it. Now because of the new feature upstream repository contributors to collaborate on a forked branch, the user saraford-tips was able to make changes directly to the branch associated with the Pull Request from user drofaras.

When user drofaras created the pull request, she (or I) kept the checkbox checked to allow edits from maintainers.

Got Feedback?

I strongly recommend using one of the existing channels for feedback. Of course, I’ll help anyone who leaves comments. It’s just that if you use one of the existing channels, your feedback and questions go to the entire team; whereas this blog is my nights and weekends project, so it’ll take me a while to respond, but I will respond. Just don’t ask me how small my queue of tips has become! O_O

our FAQ page
Visual Studio Issue Tracker on GitHub – yep! the GitHub tool window / extension is an open source project!

How to review changes in a pull request without switching branches in Visual Studio – 065

I’m disrupting your regularly scheduled tip series to talk about the awesome work the Editor Tools team has been doing at GitHub. I’m too impatient to wait for the series to catch up!

We have a GitHub Extension for Visual Studio that’s available in Visual Studio Gallery / Marketplace which is also an open source project at https://github.com/github/visualstudio. You can go to Tools – Extensions and Updates and under Online search for GitHub to install.

Once installed, you can open the GitHub tool window from View – Other Windows – GitHub

In the interest of time, I’m going to assume you are 1. connected to GitHub (either by signing in via Team Explorer or the GitHub tool window) and 2. in Team Explorer, you’re connected to a GitHub repo, as shown below

How to review changes in a pull request without switching branches

1. Go to Team Explorer – Home – Pull Requests

Clicking Pull Requests will take you to the GitHub tool window, showing all of your open pull requests for your currently connected repo.

Note by default the GitHub tool window shows Open pull requests. You can filter to see closed and all pull requests.

2. Click on the title of the pull request (e.g. added a message) to view the details.

Ignore my funky font sizes. I’m making it to 40 without computer glasses. That one summer 10 years ago was an exception.

Lots of stuff going on here. We see

User drofaras wants to submit her (yes, my alias spelled backwards) branch patch-1 (the default name GitHub supplies to branches created via the website) into master.
A”checkout” link button, but the goal of this blog post is to review changes without switching branches. (stay tuned for tomorrow)
The details about the pull request and the option to view it on GitHub.
Lastly, there’s Changes (1) because only one file has been changed.