Skip to main content
Let’s explore a GitHub repository and the common Git/GitHub workflows used to collaborate on code. A GitHub repository is a project folder that stores your files, tracks every change, and supports collaboration across branches and forks. Repositories can be public or private and are the standard unit of work on GitHub. Before examining the repository UI, here are a few core terms you should know. These are used throughout this guide with examples from the public repository fluxcd/flux2. Branches
  • A branch represents an independent line of development inside the same repository. Use feature branches for work in progress and reserve main for stable, production-ready code.
The image shows two browser windows side by side; the left window displays GitHub documentation about repositories, and the right one shows a GitHub repository interface for "fluxcd/flux2" with branch options visible.
Forking
  • Fork a repository when you want to propose changes but don’t have write access to the original. Forking creates a copy under your account where you can freely make changes and later open a pull request against the original repository.
  • When you click “Fork” on GitHub, you will be asked where to fork and whether to fork only the default branch or all branches. After forking you’ll have a repo like your-username/flux2 that shows it was forked from fluxcd/flux2.
The image shows two side-by-side web pages; the left is a GitHub Docs page explaining repository terms, and the right is a GitHub repository page for "Flux version 2," describing its purpose and features.
Cloning
  • Cloning copies the repository (including history) to your local machine. You can clone via the GitHub CLI or with native git using HTTPS or SSH.
Example with GitHub CLI:
Example with git (HTTPS):
Open the repository locally:
Typical repository contents (example):
Working with branches locally
  • Avoid making changes directly on main. Create a feature branch to isolate your work, then push it to your fork and open a pull request when ready.
Create a new branch (modern Git):
Or with the older command:
  • After creating the branch, edit files locally or use the GitHub web UI to edit and commit.
Editing and committing (web UI)
  • GitHub allows editing files directly in your fork’s web UI. When you commit to a non-default branch, GitHub will typically show an option to compare and open a pull request to merge those changes back into the target branch.
The image shows a split-screen view with GitHub documentation on repository terms on the left and a GitHub interface for editing and committing changes to a README file on the right.
Committing and pushing from your local machine
  • The -u origin feature-one flag sets the remote tracking relationship so future git push and git pull work without specifying the branch. Once pushed, open a pull request from your-username/flux2:feature-one to fluxcd/flux2:main (or the appropriate target branch).
Merging and Pull Requests
  • Merging applies changes from one branch into another. A pull request (PR) is used to propose and review those changes before merging. GitHub often provides a “Compare & pull request” prompt immediately after you push a branch.
Remotes, origin, and upstream
  • A remote is a named reference to a hosted repository URL. After cloning your fork, origin usually points to your fork. Add an upstream remote to track updates from the original repository you forked.
Add the upstream remote:
Verify remotes:
Sample output:
Syncing with upstream: common workflows
  • Fetch updates from the original project:
  • Update your local main with upstream changes:
  • Bring your feature branch up to date by rebasing or merging:
Best practices summary
  • Work on feature branches, not main.
  • Keep your fork in sync with upstream.
  • Push branches to your fork and open a pull request for review when ready.
Best practice: Work on feature branches (not main), keep your fork in sync with upstream, and open a pull request for review when your changes are ready.
Links and references

Watch Video