You can add Git commands to your main menu bar in Visual Studio.
For today’s example, you’ll see me add a Git menu with a command to open Git Bash in a command prompt.
Part 1 – Add Git Bash as an External Tool
I promised myself I wouldn’t blog about VS tips in this series. I’m sure if you searched you’ll find my old posts how the External Tools works 🙂
Just note the order in which Git Bash is listed above. In my example, it is External Tools 3. This will be needed in a second.
Part 2 – Create a Git menu in VS
Same story as above. I’m certain you can find my ancient posts, so here’s the quick version. Go to Tools – Customize – Commands
Then click Add New Menu and click Modify Selection (yeah, that’s some ancient UI) to give it a name, e.g. Git, and an icon and such if you want.
Lastly, switch the Menu bar: to Git (or whatever you called your menu). Click Add New Menu and select Tools – External Command <your number from above>
And you should be good to go!
Thanks again to Ed’s O’Reilly course on Git for Visual Studio for the inspiration!
Hmm, I wonder what could possibly be my tip for the day after yesterday’s tip!
In yesterday’s scenario, you saw how to use VS to do a diff. In today’s tip, you’ll see how to do a merge when you do `git merge branch-name` and get into a merge conflict. Hopefully you’re feeling a bit more confident when you see merge conflict now. (Yeah that’s actually my hope for myself.)
First, go to Team Explorer – Settings – Git – Global Settings and for Merge tool, click Use Visual Studio
Suppose you have a file in one branch (mine is called readme) that contains a conflict. When you go to merge into master, you’ll see a merge conflict.
You can open the mergetool by running
$ git mergetool
Follow the instructions and hit Enter.
Now the VS Merge tool appears
Clean up your readme.txt in the bottom part of the screen (or however you want to use the merge tool).
Now we’ll see that we have changes in our working directory.
You can do a `git add readme.txt` to add this file to staging.
And now we commit our merge commit via `git commit -m “merged readme”`
and the `git log` confirms our merge.
Thanks again to Ed Thomson’s Git for Visual Studio O’Reilly course! I searched for a solid hour how to manually configure VS as your external diff and merge tool. I knew I had seen it somewhere. Then I remembered Ed’s course!
Go to Team Explorer – Settings – Git – Global Settings. Then for either difftool or mergetool or both click Use Visual Studio
Suppose you have at least one commit and you’ve started making changes to that file in your working directory.
Now you can do
which will bring up a prompt asking you to confirm launching your external diff tool vsdiffmerge (the tool VS uses).
And now VS will launch and open with the diff tool showing the original Source (i.e. the file in the last commit) vs the changed file Target (the one you changed in the working directory)
BTW the reason why the tab is shown on the right side of the file tab channel in VS instead of the left is because this is a temporary file that isn’t listed Solution Explorer. Back in the day, you’d have to add this to the miscellaneous project, but not sure how that all works today. But I digress…. 🙂
So let’s see what the Use Visual Studio link did by using these two commands
$ git config diff.tool
$ git config difftool.vsdiffmerge.cmd
And the `difftool.vsdiffmerge.cmd` line is the magic line I was hunting the Internet for. Thanks Ed’s course!
Previously, I’ve blogged about how to get uncommitted changes off of master onto a new branch and I’ve blogged about how to get committed changes off of master onto a new branch from command line. Today’s tip fixes the oh no! I’ve been committing on master this entire time from within Team Explorer, thanks to blog reader Luke Kolodziej
Let’s say you’re motoring along and you realize that you’ve been checking into master (or some other wrong branch) this entire time.
Don’t delete your .git folder! There’s a better way!
First, create a branch but do not check it out!
Go to Team Explorer – Branches, then Right Click on master and select New Local Branch From. Now in the TE window, give your new branch a name, but uncheck the checkout branch.
Click Create Branch.
Now you’ll go back to your History – Master tab and do a Reset – Delete Changes (–hard) on 2nd to last commit. We’re defaulting to –hard because we have no uncommitted changes in working directory or in staging.
Now hit Refresh on the History – Master tab and you’ll see that your commits are no longer on master.
But where did this commit go?
Remember the visualization from the previous tips. Just because we rolled back the HEAD pointer doesn’t mean the commit is lost. Remember git reflog holds the truth!
Okay, now if you switch to the newline branch (e.g. using the status bar button at the bottom right), and going to View History (either from Branches – Actions – View History or from Status bar – branches list – View History)
I still to this day feel freaked out that this works. One day I’ll be able to conceptualize master, HEAD, branches, etc as pointers versus the other way around (i.e. commits suddenly disappearing if they don’t show up in the git history). One day.