gitshare

5 GitHub Features Every Developer Should Master (But Most Don't)

Ali Soukarieh

— 3 min read
Developer working on multiple GitHub repositories on laptop

You use GitHub every day. You know how to push commits, open pull requests, and merge branches. But are you using the features that actually make collaboration smoother and code safer?

Most developers stick to the basics. They've never explored the power tools buried in the Settings menu or the lesser-known buttons in the UI. That's where the magic happens.

Here are five GitHub features that transform the way teams work, but most developers never discover them.

1. Advanced Code Search with Qualifiers

You probably search for code by typing a string and hitting the search button. That works. But GitHub supports powerful search qualifiers that let you find exactly what you need in seconds.

Instead of clicking through files, try:

language:javascript filename:.config. repo:your-repo

This finds all configuration files in JavaScript projects within your repo. You can combine qualifiers for:

  • language:python — narrow by programming language
  • path:src/ — search within a specific directory
  • size:>1000 — find files above a certain byte size
  • org:your-org — search across all repos in your organization

This saves you from scrolling through hundreds of files when you need to find that one utility function or deprecated API call.

2. GitHub Discussions: The Underrated Communication Tool

Issues are for bugs and features. Pull requests are for code review. But what about conversations that don't fit either category?

GitHub Discussions is where architecture decisions, best practices, and questions live. It's like Slack for your repository, but threaded, searchable, and tied to your code.

Teams that use Discussions see benefits immediately:

  • Onboarding becomes self-serve — new contributors find answers to common questions
  • Design decisions are documented in one place, not scattered across Slack
  • Async discussions don't clutter the issue tracker

If you're running an open source project or managing a team, enabling Discussions is one of the highest-leverage features you can activate.

3. Branch Protection Rules and Rulesets

You know you can protect a branch. But most teams only enable "require PR reviews" and call it a day.

GitHub's protection rules go much deeper:

  • Require status checks — enforce passing tests before merge
  • Require code review approvals — specify how many and which roles
  • Require conversation resolution — all comments must be resolved before merge
  • Require branches to be up to date — prevent merging stale PRs
  • Restrict who can push — only repository administrators can force push

Even better: GitHub Rulesets (the newer version) let you create rule combinations and apply them across multiple branches and repos at once. If you're managing an organization, this is a game-changer for enforcing standards at scale.

4. The CODEOWNERS File: Automate Code Review Assignment

You have a file that only two people truly understand. How do you make sure those two review every change?

Create a CODEOWNERS file in your repository:

# People responsible for the entire repo
* @senior-dev @tech-lead

# Specific team owns specific paths
/src/auth/ @auth-team
/docs/ @documentation-team
/tests/ @qa-team

Now when anyone opens a PR that touches the auth folder, the auth team is automatically requested for review. GitHub enforces this as a protection rule. No more relying on developers to remember who needs to review what.

It's a small file with outsized impact on code quality and team scalability.

5. Draft Pull Requests: Get Feedback Before You're Ready

You're working on a feature. It's not ready to merge, but you want early feedback on your approach. Do you open a regular PR? Then everyone gets notified, CI/CD runs, and it looks like the code is ready for review.

GitHub Draft Pull Requests solve this cleanly. Open a PR and mark it as a draft. It shows up in your profile, but it won't:

  • Trigger notifications for reviewers
  • Block merging of other PRs
  • Run in the standard review queue

When your implementation is solid, convert it to a regular PR with one click. Now reviewers are notified and it enters the review flow properly.

This encourages early collaboration and saves teams from the awkward "sorry, still working on this" conversation.

Start Small, Build Momentum

You don't need to adopt all five at once. Start with code search qualifiers this week. Enable Discussions next. Layer in CODEOWNERS when your team is ready for it.

Each feature compounds. Search saves time. Discussions keep knowledge organized. Protection rules catch bugs before they ship. CODEOWNERS distribute the review burden. Draft PRs encourage collaboration.

Six months from now, you'll wonder how you ever worked without them.

If you're sharing code with collaborators outside your organization or need to grant access to private repos without adding them as contributors, try GitShare free for instant shareable links.

Read more