A healthy daily Git workflow

CLI examples labeled Bash work in Git Bash on Windows 10 and Windows 11, or Bash on Linux, with Git installed. Bash variable assignments such as DEFAULT_BRANCH=main are shell syntax; use Git Bash for these examples rather than pasting them into PowerShell or Command Prompt.

A repeatable workflow makes collaboration less dependent on memory. Start with an issue describing the problem, acceptance criteria and how the result will be verified. Create a short-lived branch named for the issue, change only what belongs to that task, and write commits that explain a meaningful reason, not merely “updated files.”

Inspect, stage and commit

GitHub Desktop

1. Confirm Current Branch points to your feature branch.
2. Read each file and hunk in Changes before selecting what belongs in the commit.
3. Exclude unrelated files with their checkboxes; don’t accidentally commit credentials, generated build output or local IDE state.
4. Enter a short summary such as Add inventory slot validation, plus a description explaining the reason.
5. Select Commit to feature/42-inventory; repeat for logically separate changes.
6. Use Push origin when you want the remote branch updated.

Git CLI

git status --short --branch
git diff --check
git diff
git add src/Inventory.cs
git diff --cached
git commit -m "Add inventory slot validation"
git push -u origin feature/42-inventory

src/Inventory.cs is an illustrative tracked file. Use git add -p to select individual hunks. Stage explicit paths instead of blindly using git add . when you have unrelated changes.

Run the project checks

A successful commit does not prove the feature works. Run the unit tests and build commands defined by your actual repository. For a Unity project, also test relevant scenes and serialization behavior; for infrastructure changes, validate the plan and consider a dry run. If CI fails, inspect the failed job rather than retrying blindly.

Ask for a review

Open a draft pull request early if the design needs feedback. Use a title describing the behavior, link the issue (for GitHub, Closes #42 when appropriate), explain test steps, and attach screenshots only when they communicate behavior. A reviewer needs enough context to reproduce and validate your change.

The default safe path is small change → local check → push → review → CI → merge → release. Never treat merging and deploying as synonymous: confirm the deployment pipeline and record the exact deployed commit separately.

Check before calling it done

Can another developer find the issue, understand the decision from the commit or pull-request description, reproduce the validation, and determine which release includes it? If yes, the workflow has created useful traceability, not just stored code. Continue with pull requests and release walkthrough.

Branch naming: main is an example. Use master or your repository’s actual default branch where applicable. See Git terminology.