A practical everyday workflow

At this point, the pieces should be familiar enough to connect into one default workflow.

This is not the only valid workflow, but it is a strong beginner-safe baseline.

It deliberately avoids history-rewriting steps such as rebasing or amending pushed commits in the middle of normal collaboration.

A clean branch-based default

1. Update your local repository with git pull.
2. Create a branch for the task with git switch -c ….
3. Make the changes in the working tree.
4. Inspect them with git status and git diff.
5. Stage the intended files with git add.
6. Create one or more commits with git commit -m ”…”.
7. Push the branch with git push -u origin ….
8. Open a pull request on GitHub.
9. Respond to review by pushing follow-up commits to the same branch.
10. Merge the pull request when it is ready.

Optional: signing commits

If you have configured commit signing (covered in the signing lesson), add -S to sign each commit:

git commit -S -m "Add login form"

Or enable automatic signing once with git config --global commit.gpgSign true so every commit is signed without the extra flag.

Signed commits display a “Verified” badge on GitHub. This is useful for projects where commit authenticity matters, but it is not required for everyday Git use.

Why this workflow works well

It separates concerns clearly:

• local editing and commits happen in Git
• shared review and collaboration happen on GitHub
• integration happens after the work is visible and reviewable

That structure reduces confusion, especially for beginners moving between terminal commands and the GitHub web UI.

What to keep consistent

The exact branch names and review rules may vary by team.

The important part is keeping the workflow internally consistent:

• branch for a task
• inspect before commit
• push before review
• review before merge

Stashing work in progress

Sometimes you need to switch branches before your current work is ready to commit.

Maybe you found a bug on main that needs a quick fix, or you need to pull the latest changes before continuing.

That is where git stash helps:

git stash

This saves your uncommitted changes temporarily and gives you a clean working tree.

To also stash untracked files (new files that have not been staged yet):

git stash -u

This is useful when you have created new files that you want to set aside but are not ready to commit.

After stashing, you can:

• switch branches safely
• pull updates
• fix something else

When you are ready to resume your stashed work:

git stash pop

This restores the most recent stash and removes it from the stash list. Use git stash apply if you want to keep the stash for reuse.

In the everyday workflow, stashing is useful when:

• you are interrupted mid-task and need to switch contexts quickly
• you want to pull the latest changes before committing your incomplete work
• you are experimenting and are not ready to commit yet