How to Use GitHub: Version Control and Collaboration

GitHub is where software is built — the platform hosting over 300 million repositories containing source code for everything from personal projects to the software running major companies. But it’s much more than a place to store code. It’s a collaboration platform: tracking changes, reviewing proposed modifications, discussing issues, managing project tasks, automating workflows, and documenting software in one integrated environment. You’ll find the complete rundown in our Complete Guide to Software and Apps.

Knowing how to use GitHub is a fundamental professional skill for developers, and increasingly for technical writers, data scientists, and anyone who works with code-adjacent files.

Repositories, commits, and branches — the fundamentals

A repository (repo) is the container for a project — its files, its complete history of changes, its issues, pull requests, and documentation. Create one: GitHub.com → click “+” → “New repository” → enter a name (short, lowercase, hyphen-separated), description, choose Public or Private, initialise with a README → Create repository. The README.md file is the repository’s front page — it appears by default when anyone visits the repo.

Commits are the record of each change — a snapshot of what changed, who changed it, and when. Every commit has a message and a unique hash identifier. Good commit messages are the practice that most separates professional GitHub workflows from amateur ones: “Fix login button not responding on mobile” is a good commit message; “fix stuff” is not. The message should explain what changed (not just that something did) and ideally why. A 50-character subject line optionally followed by a blank line and a longer body explanation is the standard convention.

Branches allow different versions of the repository to coexist without interfering with each other. The default branch (usually “main”) is the stable, production-ready version. Create a new branch for every new feature, bug fix, or experiment → make changes on that branch → merge it back to main only after review. This ensures main always contains working, reviewed code, and incomplete or experimental work never accidentally breaks the stable version.

• Command line: git checkout -b feature/new-login-button
• GitHub.com: the branch dropdown at the top left → type the new branch name → “Create branch”

Issues, pull requests, and code review

Open an Issue before writing code to create a record of intent, allow discussion, connect the work to a project board, and provide a reference point for the eventual PR. Reference any issue in a commit message or PR by its number (#42) — GitHub auto-links the reference, creating a documented connection between the conversation about the work and the code change that resolved it.

Pull request workflow — step by step

1. Create a branch and make changes. git checkout -b feature/add-dark-mode → make code changes → git add . → git commit -m "Add dark mode toggle to user settings" → git push origin feature/add-dark-mode. The branch is now on GitHub.
2. Open a Pull Request. Navigate to the repository on GitHub → a “Compare & pull request” button appears for recently pushed branches → click it → fill in the PR title (what the change does) and description (why and how, referencing the issue with “Closes #42”) → select reviewers → “Create pull request.”
3. Reviewers examine the changes. “Files changed” tab shows a diff of every line modified — deleted lines in red, added lines in green. Reviewers can leave inline comments by clicking the “+” next to any line, leave general comments at the PR level, and ultimately “Approve,” “Request changes,” or “Comment.”
4. Address review feedback. Make additional commits to the same branch (they automatically appear in the PR). Mark conversations as resolved when feedback is addressed. Respond to every comment, even if just acknowledging it — unresponded comments create ambiguity about whether feedback was seen.
5. Merge the Pull Request. Once approved → “Merge pull request” → choose the merge strategy (Merge commit, Squash and merge, or Rebase and merge) → Confirm. “Delete branch” to clean up the merged feature branch.
6. Issue closes automatically. If the PR description contained “Closes #42” or “Fixes #42,” GitHub automatically closes that issue when the PR is merged, keeping the project board accurate without manual follow-up.

Code review — step 3 — is the practice that most improves code quality in team projects. Reviewers bring different perspectives, catch bugs the author is too close to see, ensure code follows team conventions, and provide knowledge transfer that prevents any single person from being the only one who understands any part of the codebase. Even for solo projects, creating a PR and reviewing it the following day before merging catches errors that immediate self-review misses.

GitHub Actions — CI/CD and automation

GitHub Actions is the CI/CD and automation platform built into GitHub. Actions run automated workflows triggered by events — pushing code, opening a PR, merging to main, creating a release, or on a schedule. Workflows are defined in YAML files stored in the .github/workflows/ directory of the repository.

A basic CI pipeline workflow: trigger on every push → install project dependencies → run tests → post test results as a PR status check. Any PR with failing tests shows a red status indicator, preventing accidental merges of broken code.

Common Actions use cases:

• Automated testing: run the full test suite on every PR before anyone can merge
• Deploy on merge: deploy to staging when a PR is merged to main
• Dependency updates: Dependabot automatically opens PRs to update vulnerable packages
• Notifications: send a Slack message when a release is created or a deployment fails

GitHub Pages, the CLI, and security features

GitHub Pages provides free static website hosting directly from a repository. Enable it: repository → Settings → Pages → set Source to “Deploy from a branch” or “GitHub Actions” → choose the branch. Documentation written in Markdown renders as a website automatically. A repository with a docs/ folder, a README, and a GitHub Actions workflow to build and deploy the docs site has professional-quality project documentation at zero hosting cost.

GitHub CLI (gh) brings the full GitHub workflow to the terminal. Install from cli.github.com → gh auth login → create PRs, review issues, and manage Actions without opening a browser. Creating a PR directly from the terminal: gh pr create --title "Add dark mode" --body "Closes #42" --reviewer colleague — the PR is open with reviewers assigned in under 30 seconds.

Security features worth enabling on every repository:

• Dependabot alerts and security updates: Settings → Security → automatically opens PRs to update vulnerable dependencies
• Secret Scanning: scans commits for accidentally committed credentials (API keys, passwords, tokens) and alerts immediately
• Code Scanning (CodeQL): analyses code for security vulnerabilities, reporting them as annotated issues

Enable all three on every repository with external dependencies or credentials — they run automatically and require no ongoing attention except responding to alerts.

Forks and open source contributions

Forking creates a personal copy of someone else’s repository under your own GitHub account — the starting point for contributing to open source projects where you don’t have direct write access. Fork: navigate to any public repository → “Fork” → choose your account.

Create a branch in your fork → make the change → open a Pull Request from your fork’s branch to the original repository’s main branch. The original maintainers receive your PR and may merge it or request changes. This fork-and-PR model is how the vast majority of open source contributions are made.

GitHub Copilot ($10/month for individuals) integrates into VS Code, JetBrains, and other editors, providing real-time code suggestions, function completions, test generation, and code explanations. For learning: select any unfamiliar code → right-click → “Explain with Copilot” → get a plain-language description of what the code does. Invaluable for reading unfamiliar codebases or understanding legacy code without detailed comments. Our guide on using Zapier covers automating GitHub-triggered workflows connecting repository events to Slack and project management tools. For GitHub’s official documentation covering Actions syntax, Copilot setup, and advanced Git workflows, docs.github.com is the authoritative reference. If this sounds familiar, How to Use Google Docs is worth a look.

Essential Git commands for GitHub workflows

GitHub is the platform; Git is the underlying version control system. The commands you’ll use most often:

Common GitHub workflow mistakes

• Committing directly to main. Even on solo projects, working in branches and using PRs builds the discipline that scales when collaborators join. Direct commits to main bypass review and skip the documented PR history.
• Committing secrets accidentally. A single commit containing an API key, password, or private key creates a security incident — even if the commit is immediately reverted, the credentials are in the git history. Use a .gitignore file to exclude secrets, and enable Secret Scanning to catch anything that slips through.
• Writing uninformative commit messages. “Update,” “Fix,” “Changes” are meaningless in a history of hundreds of commits. Write messages that explain the change in context — future you (and your colleagues) will thank you when debugging six months later.
• Not using Issues before writing code. Starting a feature without an Issue means no record of the original intent, no discussion thread, and no way to link the eventual PR to the decision that prompted the work.
• Leaving stale branches uncleaned. Delete merged branches after the PR is merged. A repository with 50 old feature branches creates navigation confusion and makes it difficult to know which branches are actually active.

GitHub’s value compounds with consistent use. A repository with 50 well-described commits, a clean PR history, linked issues, and automated CI is significantly more maintainable than one where everything was committed directly to main with “Update” messages. The discipline of branching, reviewing, and writing informative commit messages takes an extra two minutes per change and returns hours when debugging, onboarding, or recovering from a mistake later. Our guide on How to Use Dropbox covers an adjacent issue.