These commands go beyond basic add/commit/push, letting you reshape and manage history more deliberately.

Rebase moves a branch’s commits so they appear on top of a different base commit, creating a cleaner, linear history compared to a regular merge, though it rewrites commit history in the process.

Cherry-picking applies one specific commit from one branch onto another, useful when you need just a single fix from another branch without merging everything else in it.

Stashing temporarily saves your uncommitted changes aside without committing them, letting you switch branches or pull updates cleanly, then reapply your changes afterward.

A soft reset moves the branch pointer but keeps your changes staged; a mixed reset (the default) moves the pointer and unstages changes; a hard reset moves the pointer and discards changes entirely — each offers a different level of “undo.”

Revert creates a brand-new commit that undoes the changes from a previous commit, preserving history rather than rewriting it — generally safer than reset for changes that have already been shared with others.

Interactive rebase lets you reorder, combine (squash), edit, or delete commits before they’re finalized, commonly used to clean up a messy commit history before merging it into a shared branch.

A detached HEAD occurs when you check out a specific commit rather than a branch, meaning any new commits you make won’t belong to any branch unless you explicitly create one — a common source of confusion for those newer to Git.

Real teams don’t just create random branches — they follow a deliberate strategy for how work flows through branches.

Git Flow is a branching model using dedicated long-lived branches (like develop, feature, release, and hotfix), providing a structured process well-suited to projects with scheduled releases.

GitHub Flow is a simpler branching model where feature branches are created from main, merged back through pull requests, and deployed continuously, well-suited to teams that release frequently.

Trunk-based development has developers commit small, frequent changes directly to a single main branch (or very short-lived branches), minimizing long-running branches and merge conflicts, often paired with feature flags.

A release branch is created to prepare and stabilize a specific version for release, allowing final bug fixes without pulling in new, unrelated feature work still happening on other branches.

A hotfix branch is created directly from a production branch to quickly fix a critical bug, then merged back into both production and the main development line to keep them in sync.

Branch naming conventions are agreed-upon patterns (like feature/login-page or fix/header-bug) that make it immediately clear what a branch is for and keep a repository’s branch list organized.

flowchart LR
    Main["main"] --> Feature["feature/checkout-flow"]
    Feature --> PR["Pull Request"]
    PR --> Main
    Main --> Release["release/v2.1"]
    Release --> Prod["Production"]
    Prod --> Hotfix["hotfix/payment-bug"]
    Hotfix --> Main
    Hotfix --> Prod
    

Beyond a basic pull request, GitHub offers tools that make collaboration at team scale more structured and reliable.

A draft pull request signals that work is still in progress and not yet ready for formal review, letting you get early visibility or feedback without triggering the usual review and merge expectations.

A pull request template automatically pre-fills new pull request descriptions with a standard structure (like a summary and checklist), ensuring contributors provide consistent, useful context.

An issue template provides a pre-defined structure for reporting bugs or requesting features, guiding contributors to include the specific information maintainers need to act on the issue.

A CODEOWNERS file designates specific people or teams as responsible for reviewing changes to particular files or folders, automatically requesting their review whenever a relevant pull request is opened.

Required reviewers is a repository setting that mandates a pull request receive approval from a specified number of people (or specific individuals) before it can be merged.

A merge commit keeps all individual commits and adds a new commit tying them together; squash and merge combines all commits from a branch into a single commit; rebase and merge replays the branch’s commits individually on top of the target branch without a merge commit at all.

GitHub Actions is GitHub’s built-in automation system — here’s the vocabulary needed to actually configure a workflow.

A workflow file is a YAML file stored in a repository’s .github/workflows folder that defines an automated process — what triggers it, and what steps it should run.

A trigger defines what activity causes a workflow to run, such as a push to a branch, a pull request being opened, or a scheduled time.

A job is a set of steps that run together on the same runner, and a workflow can contain multiple jobs that run in parallel or in a defined sequence.

A step is a single task within a job, such as checking out code, installing dependencies, or running a test command — jobs are made up of a sequence of steps.

A runner is the actual machine (provided by GitHub or self-hosted) that executes a workflow’s jobs, running the specified operating system and environment.

Secrets are encrypted values (like API keys or credentials) stored securely in a repository’s settings, made available to workflows without exposing them in the workflow file itself.

A matrix build runs the same job multiple times with different configurations (like several versions of a programming language or operating system) automatically, without duplicating the workflow definition for each combination.

Managing a repository well involves configuration options most beginners never touch.

Branch protection rules can enforce required status checks, required reviews, restrictions on who can push directly, and more, on specific branches — forming the backbone of a team’s quality-control process.

A webhook sends an automatic HTTP request to an external URL whenever a specified event happens in a repository, enabling integrations with external tools outside of GitHub Actions.

A GitHub App is installed on specific repositories with fine-grained, scoped permissions, while an OAuth App acts on behalf of a user with that user’s full permission set — GitHub Apps are generally the more secure and recommended integration approach.

A deploy key is an SSH key granting access to a single specific repository, commonly used to let a server pull the latest code during deployment without granting broader account-wide access.

A repository template lets you create new repositories pre-populated with a standard file structure, configuration, and boilerplate code, ensuring consistency across multiple similar projects.

A submodule lets you embed one Git repository inside another as a subdirectory, keeping the two histories independent while still linking a specific commit of the external repository into your project.

GitHub isn’t just for code — these tools help teams plan and track work directly alongside it.

GitHub Projects provides Kanban-style boards and customizable views for tracking issues and pull requests as tasks move through stages like “To Do,” “In Progress,” and “Done.”

A milestone groups related issues and pull requests toward a shared goal or deadline, such as a specific release version, letting you track overall progress toward that target.

Labels are customizable tags applied to issues and pull requests (like “bug,” “enhancement,” or “priority: high”) that make it easier to filter, sort, and organize a project’s work.

Using specific keywords like “Closes #42” in a pull request description automatically links it to that issue and closes the issue once the pull request is merged, keeping tasks and their resolutions connected.

A wiki is a separate, editable documentation space attached to a repository, useful for longer-form documentation that doesn’t fit naturally into a README file.

As projects grow, GitHub’s built-in security tooling becomes essential rather than optional.

2FA requires a second verification step beyond your password (like a code from an authenticator app) to log in, significantly reducing the risk of unauthorized account access.

Dependabot automatically scans a repository’s dependencies for known vulnerabilities and can open pull requests to update them to safer versions, reducing the manual effort of tracking security patches.

Security advisories let maintainers privately discuss and prepare a fix for a discovered vulnerability before publicly disclosing it, coordinating a responsible release of the fix.

Secret scanning automatically detects accidentally committed credentials (like API keys or tokens) within a repository, alerting maintainers so exposed secrets can be revoked quickly.

Code scanning analyzes a repository’s source code for known security vulnerabilities and coding errors, with CodeQL being GitHub’s own semantic code analysis engine used to power this feature.

A fine-grained personal access token can be scoped to specific repositories and specific permissions, offering much tighter security control compared to older, broadly-scoped classic tokens.

These tools let you dig into exactly what changed, when, and by whom.

git diff shows the specific line-by-line differences between two states — such as your working directory versus the last commit, or between two branches or commits directly.

Beyond a simple list, git log supports filtering by author, date range, or file, and can display history as a visual graph, making it a powerful tool for investigating how a project evolved.

git blame shows exactly which commit (and author) last modified each line of a file, useful for understanding the history and reasoning behind a specific piece of code.

A tag marks a specific commit as significant (typically a version), and a GitHub Release builds on a tag to publish a formal, downloadable snapshot of the project, often with release notes.

Semantic versioning uses a MAJOR.MINOR.PATCH numbering scheme to signal the nature of changes in a release — a pattern many projects follow when tagging and naming their GitHub releases.

The compare view lets you visually see the differences between any two branches, tags, or commits directly in GitHub’s interface, without needing to run diff commands locally.

GitHub Flow is generally simpler and well-suited for teams deploying frequently, while Git Flow’s extra structure fits better for projects with scheduled, versioned releases rather than continuous deployment.

Only on branches that are exclusively yours and haven’t been pulled by anyone else — force-pushing shared branches after a rebase can overwrite others’ work or cause serious confusion.

Not necessarily — many teams use external CI/CD tools successfully. GitHub Actions is worth adopting when you want automation tightly integrated with GitHub events without managing separate infrastructure.

A webhook is a simple one-way notification sent to a URL when an event happens, while a GitHub App is a full integration that can both receive events and make authenticated API calls back to GitHub with scoped permissions.

Generally yes — both are low-effort to enable and meaningfully reduce security risk, making them sensible defaults for almost any actively maintained repository.