This is the first in a series of posts featuring GitHubbers’ protips for improving productivity, efficiency, and more.

There are lots of hidden secrets, keyboard shortcuts, hacks, and more that can make you and your team’s GitHub experience more productive, personal, and entertaining. As someone who has been using GitHub for 10 years as an Engineering Lead and now as a Strategic Architect at GitHub, I’ve picked up a few tips and tricks over the years that might be useful to you.

Magic Markdown tables ✨

Table-magic is a lifesaver for building and maintaining complex tables in Markdown. This open source tool allows you to easily and quickly convert between several table formats including CSV, TSV, Markdown, SQL and HTML. I tend to compose tables in the built-in form and then simply copy and paste the markdown. It’s also useful for when someone sends you a CSV file that you want to quickly convert to Markdown to add to an issue.

Form showing conversion between CSV, Markdown and HTML formats.

Fun fact: This was created by fellow GitHubber @stevecat.

Search for specific copy

Since I know that all of our websites are on GitHub, if I see something that needs fixing, I just query the sentence as-is within quotes and that takes me directly to the line in a specific file. Even if you work in a company with one hundred thousand employees, if you see a bug on your corporate website, it should only take two minutes to find which repository it’s on, and open a pull request to fix it.

Screens showing search results for selected text in a repository.

Tabs or spaces? On prem, on-premise, or on-premises? Be the change you want to see in the world and make it right with a pull request. It’s a great way to keep your contributions graph green!

Use notifications as the new generation inbox

My browser homepage, and the first thing I open every morning, is GitHub’s participating notifications. This feature is super refreshing and reduces a lot of tension when most of your communications are transparent internally. Email has a purpose but transparency and collaboration are not one of them. This is a key reason why I wouldn’t be able to work with a company that uses email as the main method of communication.

Extending notifications for my own productivity flows

I’ve written three Chrome extensions that I use with GitHub to make my job easier:

  • Markwrap: My favorite (60 stars, not bad!) is a shortcut that makes any text a markdown link with the content from your clipboard. While this is simple, it’s a lifesaver if you spend your day in issues and pull requests.
  • GitHub Red Alert: Changes the bell icon to red if I have at least one notification from an issue or pull request that I’m participating in, updates in the background.
  • GitHub Open All Notifications: Adds a button to the notifications tab that opens every participating notification in a new tab. This is how I clear my queue, but I only do this for participating notifications.

Personal and professional todo list in GitHub Projects

My catalog of current and past work is added to a project board with priority columns, including columns with information about when the work was done or if it was abandoned. The todo list feature along with notifications are crucial tools in how I prioritize and manage my work.

Semantic code as a summary of review complexity

While our semantic navigate to methods is a core navigation feature, it can be used for so much more. As soon as you click the Jump to...▾ dropdown, as someone who needs to review code, you get an at-a-glance understanding of how complex and timely a review can be. If I see a few lines changed that are new (green) methods it might point to an easier code review, but If I see a lot of red with a lot of lines changed, I have to be careful to understand why we’re deleting a lot of code. In my early days as a developer someone used to tell me that writing new code is easy, and deleting old code is very hard. This can be seen by clicking on the Jump to...▾ dropdown in a pull request’s Files changed view:

In this example, there were nine lines added to the README, 68 lines added, and 18 removed in total. If you're familiar with the code (or not) you can guess that this pull request won't take long to review. At least, compared with something that has 10 times those numbers across 10 times as many files.

While there are many more to share, these are the tips I can’t live without. If any of these tips improve your productivity and save you time as much as they do for me, then this was time well spent. Keep your eyes open for more protips on our blog.

Share your tips!

Do you have a tip, trick, or hack that makes your daily life easier on GitHub? Share it with us on social media with #GitHubProtips.

Tags: