A daily Git workflow: review, verify, commit, and sync

Before you start

You are adding a short policy sentence to a shared project. Review the exact edit, run a relevant check, stage it, inspect the staged result, and then synchronize. The shell assertion below checks this exercise’s text; it is not a replacement for your real project’s tests.

Use Git 2.28 or newer in a POSIX shell on macOS/Linux, or Git Bash on Windows. Check git --version; Git's installation page covers setup. Each example starts in a new temporary folder. Keep that folder if you want to revisit your work; none of these commands removes your existing projects. The identity and signing settings below apply only to the practice repository.

Work through the example

practice=$(mktemp -d "${TMPDIR:-/tmp}/gitglow-learn.XXXXXX")
sandbox="$practice/project"
mkdir "$sandbox"
cd "$sandbox"
git init -b main
git config --local user.name "Git Learner"
git config --local user.email "learner@example.invalid"
git config --local commit.gpgsign false
git init --bare -b main origin.git
git clone origin.git alice
cd alice
git config --local user.name "Git Learner"
git config --local user.email "learner@example.invalid"
git config --local commit.gpgsign false
printf 'A small project\n' > notes.txt
git add notes.txt
git commit -m "Start notes"
git push -u origin main
cd ..
git clone origin.git bob
cd bob
git config --local user.name "Second Learner"
git config --local user.email "second@example.invalid"
git config --local commit.gpgsign false
cd ../alice

git pull --ff-only
git switch -c feature/review-policy
printf 'Review before sharing\n' >> notes.txt
git status --short
git diff
test "$(tail -n 1 notes.txt)" = 'Review before sharing'
git add notes.txt
git diff --cached --check
git diff --cached
git commit -m "Document review policy"
git push -u origin feature/review-policy
git status --short --branch

Check the result

The new feature branch has one focused commit, its upstream points to origin/feature/review-policy, and the working tree is clean. A successful text assertion prints nothing. git diff --cached --check checks patch formatting, not application correctness. The command-line push publishes the branch to the local practice remote; it does not open or merge a PR.

Try it yourself

Edit the sentence again after the check. Observe that the earlier passing check described the old content. Rerun the relevant assertion and review the new staged diff before making another commit.

If something goes wrong

If a check fails, inspect the behavior and resolve it before publishing. If a push is rejected, fetch and inspect the remote history; do not force-push as a routine recovery step. On real projects use the repository’s actual lint, tests, build, and merge process.

Use this workflow in GitGlow

Use Changes and the Free embedded terminal to review and run project checks. Free supports precise staging and commits. Pro adds file review marks and configured checkout verification, whose state can become stale after later edits. A passing verification records a checked state; it is not proof that all behavior is correct.