GitHub: What It Is, What It's For, and How to Really Use It

Plenty of people learn Git and GitHub as if they were the same thing. They are not — and understanding the difference is the first step to using both well.

• Git is the version control system. It runs on your machine, works offline, and is what actually keeps the history of the code.
• GitHub is an internet platform built around Git. It hosts repositories and adds what Git does not have: collaboration, code review, automation, publishing and a social network of developers.

You can use Git your whole life without GitHub. What you lose is everything that happens between people.

Contents

• 1 · Why GitHub exists
• 2 · The repository: the unit of everything
• 3 · The workflow in practice
• 4 · Pull Request: where code gets reviewed
• 5 · Issues and organising the work
• 6 · GitHub Actions: automation and CI/CD
• 7 · Releases, Pages and Packages
• 8 · Security
• 9 · GitHub as a portfolio
• 10 · Alternatives, and when to pick another one

1. Why GitHub exists

Git solves versioning, but it leaves three questions open:

1. Where does the official copy live? If the code only exists on your machine, a burnt-out drive ends the project.
2. How do I propose a change to another person? Git has format-patch and email — it works, but it comes from the days when Linux was developed over a mailing list.
3. How do I make sure nobody breaks the build? Git does not run tests, does not block merges, does not warn anyone.

GitHub answers all three: a remote repository as the source of truth, the pull request as a standard way to propose a change, and Actions to automate checking and deployment.

2. The repository: the unit of everything

A repository ("repo") is the project: code, history, documentation and configuration.

• Public — anyone can see and clone it. It is what sustains open source.
• Private — only whoever you authorise. Free and unlimited since 2019, personal accounts included.

Three files define the first impression of your repository:

README.md          # what it is, how to run it, how to contribute — it becomes the repository's cover
.gitignore         # what must never be versioned (node_modules, .env, build)
LICENSE            # without a licence, "public" does not mean "free to use"

A public repository without a licence is, legally, "all rights reserved". If you want people to use your code, pick a licence — MIT and Apache 2.0 are the most common.

And the warning that outweighs all the others: never commit a secret. A token, a password or a private key in a public repository gets swept up by bots within minutes. If it happened, revoke the credential before anything else — deleting the commit is not enough, because it has already been read.

3. The workflow in practice

The cycle that practically every team uses:

# 1. Bring in the current state of the main branch
git switch main
git pull

# 2. Create a branch for your task
git switch -c feat/filtro-por-assunto

# 3. Work in small, descriptive commits
git add .
git commit -m "feat(blog): filtro por assunto na listagem"

# 4. Publish the branch
git push -u origin feat/filtro-por-assunto

# 5. Open the Pull Request (from the site or from the gh CLI)
gh pr create --fill

Why a branch instead of committing straight onto main? Because main should always be publishable. Every change goes through a place where it can be reviewed, tested and undone without affecting whoever depends on it.

The gh CLI

GitHub has a command-line client that saves you from going back to the browser:

gh auth login                          # authenticates the machine
gh repo create meu-projeto --private   # creates the repository
gh repo clone usuario/projeto
gh pr create --fill                    # opens a PR with title/body from the commits
gh pr list
gh pr checkout 42                      # pulls down someone else's PR to test it
gh pr review 42 --approve
gh pr merge 42 --squash --delete-branch
gh issue create --title "Bug no filtro" --body "Passos para reproduzir..."
gh run list                            # Actions runs
gh run watch                           # follows the current run

4. Pull Request: where code gets reviewed

The Pull Request (PR) is the heart of GitHub. It says: "I have these changes on this branch and I want to integrate them into that one; please review".

A PR brings together in one place:

• the full diff, commentable line by line;
• the discussion about the decisions;
• the result of the automation (tests, lint, build, deploy preview);
• the approvals required before merging.

What makes a good PR:

Three ways to merge, and when to use each:

• Merge commit — preserves every commit and records the integration. Good when the branch's history has value.
• Squash and merge — collapses everything into a single commit on main. The default for most teams: clean history, one commit per feature.
• Rebase and merge — replays the commits with no merge commit. Linear history, but it rewrites the hashes.

Branch protection

In the repository settings you define the rules for main:

• require a PR (block direct pushes);
• require N approvals;
• require the CI checks to pass;
• require the branch to be up to date before merging;
• require signed commits.

This is what turns good intentions into process. Without it, "we agreed to always open a PR" lasts until the first tight Friday.

5. Issues and organising the work

Issues are the project's tasks, bugs and ideas — each with its own discussion, assignee, labels and milestone.

# In the body of the commit or the PR, this closes the issue automatically on merge:
git commit -m "fix: corrige contraste do tema claro

Closes #42"

Features worth knowing:

• Labels — bug, enhancement, good first issue. The last one is the classic invitation for new contributors.
• Milestones — group issues by delivery or version.
• Projects — a kanban-style board wired to the issues and PRs, which move on their own as the status changes.
• Discussions — for questions and open proposals, without polluting the issues with things that are not tasks.
• Templates — .github/ISSUE_TEMPLATE and PULL_REQUEST_TEMPLATE.md standardise what you need to receive.

6. GitHub Actions: automation and CI/CD

Actions runs tasks automatically when something happens in the repository: a push, an opened PR, a created tag, a time of day.

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  verificar:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

With that, every PR reaches the reviewer with lint, tests and build already verified. The most common uses:

• CI — test and validate every change.
• CD — publish automatically on merge into main.
• Scheduled (on: schedule) — periodic routines, such as checking for broken links or updating dependencies.
• Quality — coverage, static analysis, licence checking.

Two tips that spare you pain: use secrets for credentials (never write a token into the YAML) and pin the version of the actions (@v4, or better, the commit hash) so a third party's update does not catch you by surprise.

7. Releases, Pages and Packages

• Releases — package a tag with release notes and binaries. It is where users download the finished version, without needing to understand Git.
• GitHub Pages — free static hosting straight from the repository. Perfect for documentation, a landing page and a portfolio.
• Packages — a package registry (npm, Docker, Maven, NuGet) wired into the repository's permissions.
• Gists — standalone snippets of code, versioned, public or secret. Great for sharing a script.

gh release create v1.2.0 --generate-notes
gh release upload v1.2.0 ./dist/app.zip

8. Security

GitHub bundles several layers of protection — and most of them just need switching on:

• Dependabot — opens a PR automatically when one of your dependencies has a known vulnerability or a new version.
• Secret scanning — detects a committed token and, in many cases, notifies the provider to revoke it.
• Code scanning (CodeQL) — static analysis looking for vulnerability patterns in your code.
• Security advisories — a private channel for someone to report a flaw without exposing the problem to the world.
• Mandatory 2FA — since 2023 for anyone contributing code on the platform.

And on your side: use SSH or a token with minimum scope, never a password; and prefer fine-grained tokens, which grant access to specific repositories instead of the whole account.

# SSH key: generate it, add it to the agent and register the public one on GitHub
ssh-keygen -t ed25519 -C "voce@email.com"
ssh-add ~/.ssh/id_ed25519
gh ssh-key add ~/.ssh/id_ed25519.pub
ssh -T git@github.com    # tests the connection

9. GitHub as a portfolio

For anyone building a career, the GitHub profile usually gets read before the CV. What really counts:

1. A README in the projects. A repository without a README looks abandoned, however good the code is. Explain the problem, the solution, how to run it and what you learned.
2. Commits with a real message. A history of "update", "test" and "asdf" says a lot about how you would work in a team.
3. A few well-made projects > many half-finished ones. Three complete repositories are worth more than thirty copied tutorials.
4. A profile README. A repository named after your username becomes the front page of your profile.
5. A contribution to someone else's project. An accepted PR on a real project shows you can work with other people's code — and it is worth more than a full contribution graph.

About the "little green squares": consistency is good, but nobody serious hires because of it. A daily commit with no substance is easy to spot.

10. Alternatives, and when to pick another one

For a personal project, open source and a portfolio, GitHub is the default choice because of its reach. For a company that requires on-premise data, self-hosted GitLab and Gitea usually enter the conversation.

In short

Git keeps the history of your code. GitHub is where that history meets other people — to review, automate, publish and collaborate.

If you are starting out, the shortest path to real benefit:

1. Push up a project of yours with a README and a licence.
2. Work in branches and open PRs even when you are on your own — the habit is what counts.
3. Turn on a simple CI workflow running the tests.
4. Enable Dependabot.
5. Find a good first issue on a project you use and send your first PR.

The fifth step is the one that changes the level: it is when GitHub stops being a backup of your code and becomes the place where you work with the rest of the world.