clone#

git clone https://repository.git — Creates a local copy of a remote repository, downloading all files, branches, and commit history into a new directory on your machine. This is typically the first command you run when joining and existing project.

branch#

git branch — Lists all local branches in the repository, marking the currently checked-out branch with an asterisk. Add -a to include remote branches or -v to see the latest commit on each.

git branch branch_name — Creates a new branch with the given name pointing at your current commit, but does not switch you to it. Follow with a git switch branch_name to switch to it.

TIP

You can use the command git switch -c branch_name to create and switch in one operation.

git branch -D branch_name — Force deletes the named local branch, even if it has unmerged changes that would otherwise be lost. Use lowercase -d instead for a safer delete that blocks if the branch hasn’t been merged.

NOTE

Because we leverage squash merges into main the -d will always think that there are unmerged changes.

switch#

git switch branch_name — Switches your working directory to the specified branch, updating your files to match that branch’s latest commit. Add -c to create and switch to a new branch in one step.

status#

git status — Shows the current state of your working directory and staging area, including which files have been modified, staged for commit, or are untracked. It’s the go-to command for checking where you stand before staging, committing or switching branches.

add#

git add . — Stages all new and modified files in the current directory (and its subdirectories) for the next commit. Use with care, it can be quick to sweep in files you didn’t intend to include, so a git status check before hand is a good habit.

TIP

A clean .gitignore will be your first line of defense. If git status is consistently showing files you don’t want to track, node_modules/, build artifacts, .env files, etc., add them to .gitignore.

commit#

git commit -m "message" — Records your staged changes to the local repository with a short inline message describing what changed.

TIP

Keep messages clear and meaningful (e.g., “fix login redirect bug” rather than “stuff”)

For anything needing more detail, omit the -m flag to open your editor and write a full multi-line message with a subject line and body.

push#

git push --set-upstream origin branch_name — Pushes a local branch to the remote (origin) for the first time and links it to a remote tracking branch of the same name, so future git push and git pull commands work without specifying the remote and branch.

TIP

To skip this entirely on new branches, set git config --global push.autoSetupRemote true. With this enabled, a plain git push on a brand new local branch will automatically create the matching upstream branch on origin and link them, so you do not have to remember the --set-upstream flag.

pull#

git pull — Fetches the latest changes from the remote branch and merges them into your current local branch in one step. Run it before starting new work and before pushing to minimize merge conflicts.

NOTE

Under the hood it’s a git fetch followed by a git merge.

restore#

git restore file_name — Discards local changes to the specified file, restoring it to match the latest commit on your current branch. Add --staged to unstage a file without losing your edits, making it the modern replacement for git reset HEAD file_name. You can also combine it with --staged --worktree to fully revert a staged change.

NOTE

You’ll often see git checkout used for both branch switching and file restoration in older documentation, tutorials and forums. This double duty has caused enough pain that git switch and git restore were later introduced as safer more explicit alternatives.

fetch#

git fetch --prune — Downloads the latest refs and objects from the remote and simultaneously removes any remote-tracking branches in your local repo whose upstream counterparts no longer exist. This is a great housekeeping command to run periodically so git branch -a doesn’t accumulate stale references to branches that have already been deleted on the remote.

Working on the wrong branch#

If you have uncomitted changes, create a new branch, make your commit and work as normal. You can then discard any changes on main.

1
git switch -c feature/cool-feature
2
git status
3
git add .
4
git commit -m "..."
5
git push

You’re on main with commits that should be on a branch#

If you already have commits, the trick is to create a new branch, switch back to main and reset back to match the remote.

1
git switch -c feature/cool-feature
2
git switch main
3
git reset --hard origin/main
4
git switch feature/cool-feature

Workflows#

enforce-stage-source.yml

1
name: Enforce stage source
2
on:
3
  pull_request: {}
4

5
jobs:
6
  check-source:
7
    runs-on: ubuntu-latest
8
    steps:
9
      - name: Validate source branch
10
        run: |
11
          if [[ "${{ github.head_ref }}" != "main" ]]; then
12
            echo "::error::Stage PRs must come from main, not ${{ github.head_ref }}"
13
            exit 1
14
          fi

enforce-prod-source.yml

1
name: Enforce production source
2
on:
3
  pull_request: {}
4

5
jobs:
6
  check-source:
7
    runs-on: ubuntu-latest
8
    steps:
9
      - name: Validate source branch
10
        run: |
11
          if [[ "${{ github.head_ref }}" != "stage" ]]; then
12
            echo "::error::Production PRs must come from stage, not ${{ github.head_ref }}"
13
            exit 1
14
          fi

Protect Main Branches#

Target repositories: All repositories
Target branches: Default
Restrict deletions: Yes
Require pull request before merging: Yes
 Required approvals: 0
 Dismiss stale pull request approvals when new commits are pushed: Yes
 Allowed merge methods: Squash
Block force pushes: Yes
Require code scanning results: Yes

Protect Stage Branches#

Target repositories: All repositories
Target branches: stage
Restrict deletions: Yes
Require pull request before merging: Yes
 Required approvals: 0
 Dismiss stale pull request approvals when new commits are pushed: Yes
 Allowed merge methods: Merge
Block force pushes: Yes
Require workflows to pass before merging: Yes
 Do not require workflows on creation: Yes
 Enforce stage source
  1. Add workflow
  2. Select gh-workflows repository
  3. Select main branch
  4. Enter path to enforce-stage-source.yml file

Protect Main Branches#

Target repositories: All repositories
Target branches: prod
Restrict deletions: Yes
Require pull request before merging: Yes
 Required approvals: 0
 Dismiss stale pull request approvals when new commits are pushed: Yes
 Allowed merge methods: Merge
Block force pushes: Yes
Require workflows to pass before merging: Yes
 Do not require workflows on creation: Yes
 Enforce production source
  1. Add workflow
  2. Select gh-workflows repository
  3. Select main branch
  4. Enter path to enforce-prod-source.yml file