Unlocking the Power of GitHub: Tips and Tricks

April Yoho - May 22 '23 - - Dev Community

When working on any platform or with any tool, finding out about shortcuts that make your life easier saves you not only time, but also makes you a better engineer. In this blog, I am sharing with you 5 built-in features on GitHub that I absolutely love! Actually, that’s not true. When myself and Christopher Harrison kicked off this YouTube episode I planned for 5, but got carried away. So below, find 7 awesome GitHub shortcuts that will make your life easier as an engineer:

  1. Edit your code quickly using the GitHub web editor.

When I am working on a project and I need to quickly open a web editor to make changes to a README or other document, I use the web editor. It saves the time of opening a project for a quick change, or even if you’re not able to open up and work from your default machine (or in my case, my laptop seizes up and I can’t open Visual Studio Code).

  1. Quickly search for any file in your repo. I struggle to find files in larger, more complex projects. Being able to search for files easily, and effectively, even when you misspell something. I can access the files I need, fast. Even better knowing that GitHub code search is now generally available!

  2. Highlight code snippets to create an issue or share with your team. So often you share changes that are made to a file, then have to give reference as to where those changes were made, that takes time, and causes disruption and loss of focus. Being able to highlight the code that I want to share, easy and fast. It also really helps me when I need to create an issue for something in my existing code base.

  3. Link your pull requests with your Issues. Traceability and communication are two of the many components that build high performing engineering teams. While this is a simple feature, it ensures that you have traceability from your Issues to your pull requests, as well as continuing that communication and keeping your teams up-to-date. Linking a pull request to an issue is a simple feature, but one that I use every day.

  4. Comment on Pull Requests in-line and add suggestions. Another game changer for myself and my team. Previously, when commenting on a pull request, you would have to hunt for the comments and find them. Often that took up too much time, especially if you wanted to make suggestions or changes to someone else’s code. Being able to make a suggestion in the codebase and easily accept the change AND add it to your pull request makes code reviews so much easier and faster.

  5. Create saved replies to save time on comments. When work is repetitive little tricks like this enable you to save just a few minutes when commenting on PRs and projects. I like to add my favorite phrases using saved replies and emojis to respond to folks on my teams.

  6. Bonus: Trigger a GitHub Action workflow when you close a PR. While this is just a trigger mechanism, I put this workflow into almost all of my GitHub repositories. This is my clean up task, I use the built in automation of GitHub Actions to delete any deployed cloud resources, confirm my PR is closed when a branch merges, etc. I am basically cleaning up after myself.

GitHub is more than just a source control system, it’s a whole platform of tools to help engineers plan, write, deploy and manage their applications. GitHub has evolved over the last few years at an amazing rate. To help, GitHub’s Enterprise Advocates have started a new series: GitHub in My Day Job, hosted by April Edwards and Christopher Harrison. While these episodes run live, giving you the opportunity to ask questions, each episode is also available on demand for you to watch later and quickly navigate to the content that matters most to you.

We hope that we can share our knowledge with you, the community. Please feel free to share feedback on topics that you would like to see us cover!

Further Learning:

Watch the full episode
GitHub in My Day Job on YouTube
GitHub Blog

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .