Tag: github

How to press ‘y’ to navigate to the permalink for a file’s exact commit ID on GitHub.com – 052

Suppose you had a question about the contents of a file at an exact moment in time (or in git-speak: at an exact commit in time). If you were to visit the repo and navigate directly either to a file or the line in question in a file, e.g. https://github.com/saraford/your-moment-of-github-zen/blob/master/main.js#L74 showing the line

mainWindow.webContents.openDevTools();

you might forget or not even realize (like me) that you’re copying the link for the latest version of that file on master (or in git-speak: the version of the file at the current head of master).

In other words, if someone were to come along and make a change to this file, your link to this line of code at the latest commit on master might be a link to a totally different line of code instead of the openDevTools() link.

Press the `y` key and you’ll see that the page seems to refresh. Well, yes and no. The page has updated, but look at the URL now.

https://github.com/saraford/your-moment-of-github-zen/blob/f06f035cfed7c0ea05db8bd3cc25b22c43cea6d7/main.js#L74

now you got the permalink to that exact line of code!

This shortcut is the functional equivalent of clicking Code – Commit – Browse the repository at this point in the history – clicking the file (e.g. main.js) – and then clicking the line number.

This shortcut works for any branch name, specific commit SHAs, and tags, according to the docs. E.g. suppose you were looking at main.js on a branch called windows-fix located at https://github.com/saraford-tips/your-moment-of-github-zen/blob/windows-fix/main.js and you pressed the `y` key. The URL would change to https://github.com/saraford-tips/your-moment-of-github-zen/blob/811aacbd492044c8a02536129edf42862d0a593d/main.js

I hate not having a photo to go alongside a tip, so here’s a picture of a Great Dane next to a small (terrier?) dog, aka how I feel standing next to tall people.

Great Dane standing next to small dog

photo taken from https://flic.kr/p/b4RGX8

How to view the name and email that is associated with a commit on GitHub via the web browser – 051

Suppose you want to verify your email in your Git logs hosted on GitHub without pulling down the repository.

Navigate to the desired commit (via Code tab – Commits link – Commit)

commit displayed on github

Now in the URL shown in your web browser, add the extension .patch and you’ll see the name and email from your .gitconfig.

printout from a format-patch displayed in plain text

btw, in case you want to know what’s going on, this is actually the git format-patch command, where GitHub is displaying the output.

Since the commit ID is 32473a3, we can do

$ git format-patch 32473a3~1..32473a3

git format-patch 32473a3~1..32473a3

to get the same result in the command line.

showing generated patch file from command line

How to hide your email address in your Git commits but still get contributions to show up on your GitHub profile – 050

I have good news and bad news. Let’s start with the good news.

If you want to get credit for your commits, but don’t want to expose your GitHub email address in the commit logs (have you checked the logs? why haven’t you checked the logs*?), here are the steps you can take. 

contributions graph on GitHub profile

First, in GitHub go to Settings – Email – Keep my email address private

Keep my email address private checkbox

You’ll notice a new email saraford-tips@users.noreply.github.com for you to use for your Git commits.

Next, you’ll need to update Git to use this new noreply email instead of your real one. You can do this either from the command line or from GitHub Desktop.

From the command line, provided that you want to change your email address globally across all repos, you’ll simply do

$ git config –global user.email “your-username@users.noreply.github.com”

and then to verify, type

$ git config –global user.email

for example

git bash showing --global user.email changed

Or if you want to use GitHub Desktop, it’s just at Options – Configure Git which will do the same as the –global flag, hence the red circle around the global gitconfig message.

Configure git username and email address

You can read more in the GitHub Documentation for keeping your email address private, e.g. how to change only a specific repo, etc.

And now for the bad news.

This change will only apply moving forward. If you’ve been using your personal email address in previous Git commits, you’ll need to do some work to scrub the logs (where possible). Check out the GitHub Documentation for changing author info.

*My favorite all-time scary movie is the 1979 version of When a Stranger Calls. Well, not the entire movie, but just the first 15 minutes. And I don’t think it holds up anymore with smart phones being the norm. But wow, that was something scary! And yeah, you should check the logs… just to make sure you don’t have your email address committed that you don’t want others to see. 

How to use Git.io to shorten GitHub URLs and create vanity URLs – 049

Suppose you want to shorten the URL to a particular location on GitHub. Or perhaps you want to create a vanity URL that goes directly to your GitHub profile, e.g. https://git.io/saraford. You can use Git.io: GitHub URL Shortener.

To shorten a URL, open your favorite command prompt (via Git Shell) and type in

$  curl -i https://git.io -F "url=https://github.com/saraford/your-moment-of-github-zen/issues"

in the response, you’ll see your shorten URL!

Location: https://git.io/vMdeF

To create a vanity URL for your GitHub profile,

$ curl -i https://git.io -F "url=https://github.com/saraford" -F "code=saraford"

in the response, you’ll see a new way to refer to your GitHub profile!

Location: https://git.io/saraford

How to automatically close Issue(s) when you push a commit to GitHub – 046

You might have discovered this feature accidentally if you’ve ever pushed a fix up to GitHub using the magic words in your commit message. The story goes: You’ve committed a fix and pushed it to GitHub. Next you go to the Issue to close it, but to your (pleasant) surprise, the issue is already closed! How did it know?

I put pleasant in parenthesis because I hate technological surprises. I mean surprises are good, but I want to know what caused the surprise, so I’ll know how to surprise myself again in the future!

Two things must be true for your commit message to close an issue (see GitHub help article)

  1. contains a deviation of the words fix, close, or resolve, immediately followed by #<issue-number>
  2. the commit is on the default* branch (which is master by default, unless you or a repo maintainer has changed it)

If you take away nothing else from this tip, take away this: do not try to use the word Issue, e.g. Fix Issue #3 Otherwise, it won’t work. Gets me every time.

For example #1, suppose you have a repo where you want to delete a file that isn’t being used. You or someone else has created an Issue to track this work.

Delete Class1.cs #3 issue on github

You’ve fired up Visual Studio**, deleted the file from solution explorer (and saved the .csproj so the reference to the file is gone), and opened up the Team Explorer – Changes window to commit the change. You can type in “Fix #3” as the commit message to close Issue #3 in your repo.

commit message: Fix #3

Now when you return to your Issue, you’ll see it has been automatically closed with references to the commit automatically added to the Issue timeline.

Delete Class1.cs showing as Closed with how closed messages added to timeline

Now let’s say you are like me and after years and years and years of habit (and we’re talking about habit since the good ol’ days of RAID – where my MSFTies at!?!?), you put the word Issue in between the Fix and the #3. The Issue won’t get closed and you’ll have to close it manually.

 

And yes, as this blog post title implies, you can close multiple Issues.

For non-VS users out there, let’s do a command line example. Let’s say you have two Issues out there on your repo on GitHub. I’ll use close this time***, but close(s|d), fix(es|ed), or resolve(s|d) will all work.

git commit -am "Close #4 and Close #5"

*We’ll talk more about default branches later, but if you want to confirm the default branch, go to the branches link above the language bar in your repo.
**As if I could keep myself from blogging re Visual Studio Smile This is a Windows-first, non-Windows friendly blog, meaning I’m doing everything this from a Windows point of view. At some point the series will contain lots of Windows-only tips, but for now, I’m trying to straight the right balance in being non-Windows friendly.
*** In the command prompt example, I edited a readme file. I’m using the shortcut -am to do both the git add and the git commit at same time. More on these shortcuts later!

How to create a Pull Request for an existing branch in your own repo in GitHub – 019

Yep, if you’ve been reading this series, you knew this tip was coming.

For explanation purposes, I’m going to ignore for now the Compare & pull request buttons you’ve probably been seeing if you’ve been following along at home. Why? Because I find it more straightforward to explain how things work when you have to set it up manually the first few times. Otherwise, it’s just magic happening under the scenes.

The scenario is you’ve created a README.md file in a branch called readme-draft on your repo. You created the README.md file in this non-master branch, because you wanted a few days to work (and sleep) on your writing. Now that you are ready to commit the file, you want to merge it into master. Let’s also assume (for now) you are like me, a solo developer on many of your repos.

(aside: I’m pretty sure the only way to do a merge on GitHub is via a Pull Request, even if you are the only developer. Here’s the corresponding SO question/answer to sanity check.)

First, you’ll click on Pull requests tab. (It doesn’t matter which branch you are currently viewing.) Then click on the New pull request button.

New Pull Request button on Pull Request tab

Next you’ll need to specify that you want the readme-draft branch (head) to be merged into the master branch (base).

(If you tried the other way, you’ll immediately get a message that “readme-draft is up to date with all commits from master,” because remember, the readme-draft was based from master only 2 commits ago.)

compare: master dropdown button switching to readme-draft

Alrighty, lots happening on this page, but let’s chill, and only pay attention to 3 things, plus some lagniappe.

Comparing changes page of a Pull Request

On this comparing change page, you’ll see the following items:

  1. Able to merge. These branches can be automatically merged – Awesome. This means no merge conflict, so we’re good. We’ll cover merge conflicts later. It’s only mid-January Smile
  2. Create pull request – This is the action you’ll take next.
  3. 2 commits – something that took a bit of getting used to for me is that this is the number of commits included in this branch, and not the number of files.
  4. Guides – using pull requests –  there’s a little help button sitting off to the far side taking you to the about pull requests guide.

Press the Create pull request button and the Open a pull request form appears.

Open a pull request form page

“What? Another commit form????”  Well, that was my first thought creating my first Pull Request (or PR as I might sometime refer to it as).

My second thought was, “why doesn’t GitHub just use my last commit?” But recall, your last commit is just that… your last commit to a branch. It might say “fix typo” whereas the other 5 commits might talk about all the changes and updates you made to that branch. So you need a new form to represent all your work on that branch.

My third thought was “okay, on closer look, this isn’t the standard commit form after all. So… where does this title and description go?” Glad I asked. This title “Updated the readme” and description “In this pull request…” will be shown as an item on the Pull Request page for the repo (the page when you click on the Pull Request tab.) Think of this as the overall description for your branch.

Without further ado, click Create pull request.

Updated the readme pull request created

And there you go! Your first pull request!

The Pull Request has been created. Note this does not mean your code has been merged. This just means your branch as been marked as wanting to be merged, in case there are other contributors on your repo that want to give you feedback. Your code will be merged once you click the Merge pull request button, but we’ll stop here for today. We’ll cover everything on this page in future tips.

Instead of providing end-to-end walkthroughs, my goal is to provide the smallest, yet practical, bites of information to chew on for 24 hours at a time. This is my personal spin on how to best deep dive into things.

How to make a commit to a non-default branch using GitHub – 018

Suppose you have multiple branches, and you want to make a commit to a branch that isn’t the default branch (which is almost always master, unless a repo maintainer changed it).

In my random-example repo, I added a README.md file to a readme-draft branch. Suppose you have a similar README.md file in a non-master (or non-default) branch in your repo and you want to update it via the GitHub UI.

First you want to switch to the readme-draft branch by clicking the Branch: master dropdown button.

Branch: master dropdown button switching to readme-draft branch

Second, you’ll want to edit the README.md file. See previous tips for end-to-end walkthrough. In my example, I added a link to the MSDN documentation where I got the sample code.

Next, to save your edits to the README.md file, you can either commit to the readme-draft branch or create a new branch based on the readme-draft branch.

Commit changes either on readme-draft or new branch off of readme-draft

Now if this seems a bit different, it should! Before we were committing to the master branch. This time we’re on a different branch than master, and we could create a new branch (`readme-draft-draft` or `whatever-1`) based off of this current branch (readme-draft).

Again, this is one of those things about Git you have to get comfortable with. Creating a branch is a lightweight process because of how Git works (more on that later, probably late Feb or early March).

For this example, let’s keep it simple. You can commit directly to the current branch, i.e. readme-draft, by clicking the Commit changes button.

Now if you click Code (or go to the repo homepage), you’ll see the following changes:

repo file listing for branch readme-draft 2 commits ahead of master

A few things to notice in the previous screenshot:

  1. You are still viewing the readme-draft branch.
  2. This branch is two commits ahead (1. the creation of the readme.md file – done prior to this tip, and 2. adding the hyperlink to the readme in this commit)
  3. The text `System.Random() from MSDN Documentation` is now blue, indicating the committed hyperlink change