Git Course 0%

Decision guides

Eight questions, eight answers. Each guide also appears in the lesson that teaches it; this page collects them so you can find one under pressure.

1. I changed a file, now what?

Decision guide: I changed a file, what now? A flowchart. Start: run git status. Question: is the change what you meant? If no: git restore the file, or edit again. If yes: run git diff and read it. Question: does it belong in the next commit? If no: leave it unstaged, or stash it. If yes: git add the file, then git diff --staged. Question: is the commit complete and about one thing? If no: add more files or stage part with add -p. If yes: git commit -m with a message and issue number. Question: ready to share? If yes: git pull then git push. Otherwise keep working. git status Is the change whatyou meant? no → edit again, orgit restore <file> git diff (read it) Does it belong in thenext commit? no → leave it unstaged,or git stash it git add <file> → git diff --staged Complete, and aboutone thing? no → stage more files,or part with add -p git commit -m "type: … (#n)"then pull, then push when ready yes ↓yes ↓yes ↓yes ↓ nononoyes Every "no" leads back into the same loop; nothing is lost except with git restore.
After any edit: status, then diff, then stage, then check the staged diff, then commit. Every "no" answer has a safe exit.

The everyday loop, in full, is lesson 5.9.

2. I want to undo something

Decision guide: I want to undo something. Which command? A flowchart. Start by running git status and git log. First question: is the thing you want to undo committed? If no, and it is staged, git restore --staged the file; if it is only edited, git restore the file, which is permanent; if you just want to park it, git stash. If yes, it is committed, second question: has it been pushed where others can see it? If yes, git revert the hash, which adds an undo commit and is the only safe choice. If no, third question: is it the most recent commit and only the message or a missing file is wrong? If yes, git commit --amend. If no, git reset, choosing soft to keep the change staged, mixed to keep it in the files, or hard to discard it. A final note says if you cannot see the commit at all, run git reflog first. git status · git log Is it committed? check git status no — not committed git restore --staged <f> to unstage, keeping the edit git restore <f> (permanent) just parking it? git stash back with git stash pop Has it been pushed? can anyone else see it? yes — pushed git revert <hash> adds an undo commit; the only safe choice here Latest commit, and only the message or a file is wrong? yes git commit --amend stage the file first no — move the branch back git reset <mode> <target> --soft keeps the change staged, ready to re-commit --mixed keeps the change in your files (the default) --hard discards it; check git status first no or yes no no Cannot see the commit at all? Run git reflog first: it lists every position HEAD has held. Everything on the amber path rewrites history, so it is only for commits you have not pushed.
Two questions decide almost everything: is it committed, and has it been pushed?

The full table of situations and commands is lesson 12.10.

3. I want the team's latest changes

Decision guide: I want the team's latest changes Start by asking whether you have uncommitted work. If yes, commit it or stash it first. Then ask whether you only want to look at what has arrived: if so, run git fetch, which changes no files, and compare with git log HEAD..origin/main. If you want the changes in your branch, run git pull, which is fetch plus merge or rebase depending on your setting. If the pull reports divergence, that is the two-fix situation in lesson 7.5. A note says to do this before starting any new branch, because branching from stale main is the commonest avoidable cause of conflicts. git status Anything uncommitted? including untracked files yes → commit it, or git stash -u Do you want it in your branch, or just to look? just look git fetch then git log HEAD..origin/main get it git pull = fetch + merge or rebase If the pull says the branches have diverged, that is lesson 7.5: merge or rebase, and both are fine on your own branch. Do this before creating any new branch. Branching from a stale main is the commonest avoidable cause of conflicts.
Commit or stash first; fetch to look, pull to take.

Fetch and pull are compared in lesson 7.5.

4. Merge or rebase?

Decision guide: merge or rebase? First question: has the branch been pushed and does anyone else have it? If yes, merge; rebasing would rewrite commits other people hold. If it is yours alone, second question: does your team require a linear history? If yes, rebase and force-push with a lease. If not, either works, so use whichever your team's merge button uses. A note says the platform's squash-on-merge option gives a tidy history with no rewriting on your side, and that rebasing your own branch onto an updated main before review is normal and encouraged. Is the branch pushed, and does anyone else have it? yes → merge rebasing would rewrite commits they hold Does your team require a linear history? yes → rebase git rebase main git push --force-with-lease no → either works use whatever your team's merge button does Squash on merge gives a tidy main with no rewriting on your side, which is why most teams choose it. Rebasing your own unpushed branch onto an updated main before review is normal and encouraged.
If anyone else has the branch, merge. If it is yours and the team wants a straight history, rebase.

Both are explained in lesson 6.7, and what each leaves on main is lesson 13.4.

5. Which authentication method?

Decision guide: which authentication method? First: is this you, on your own machine? If yes, prefer SSH, which means one key per machine and no prompts, or HTTPS with a token in a credential manager if your network blocks SSH. If it is not you but a server or a script, ask whether it needs one repository or many. One repository: a deploy key, read-only if possible. Many, or the platform API: a project or group access token on GitLab, or a fine-grained token or an app on GitHub, always with an expiry. A note says never to use a personal token for automation and never to put any credential in the repository. Is it you, on your own machine? yes → SSH key one key per machine, no prompts, no expiry to miss SSH blocked by the network? HTTPS + token + credential manager A server or script: one repository, or many? one → deploy key read-only if it only clones many, or the API project or group token, or a fine-grained token — always with an expiry Never use a personal token for automation: it carries all your access and stops working when you leave. Never put any credential in the repository. Pipeline secrets belong in CI/CD variables or Actions secrets.
You on your machine: an SSH key. A server or a script: a deploy key, or a scoped token with an expiry.

The detail is Section 8, and the platform pages are lesson 9.12 and lesson 10.12.

6. Which branch do I start from?

Decision guide: which branch do I start from? First: is production broken right now? If yes, this is a hotfix, so branch from the released tag or the release branch, not from main, and plan to get the fix onto both. If not, second question: does the repository have a develop branch? If yes, it is Git Flow, so branch from develop. If not, branch from current main, after pulling. A note says to check the branch list and CONTRIBUTING.md when unsure, and that branching from a stale main is the most common avoidable cause of conflicts. Is production broken right now? yes → hotfix branch from the released tag or the release branch then get it onto main too Does the repository have a develop branch? yes → Git Flow branch from develop, and target it in the MR no → branch from current main git switch main && git pull && git switch -c … Unsure? Read the branch list and CONTRIBUTING.md; between them they answer this in under a minute.
Production broken means a hotfix from the released tag. A develop branch means Git Flow. Otherwise, current main.

The four kinds of work are lesson 13.2, and the strategies are lesson 13.3.

7. My push was rejected

Decision guide: my push was rejected Read the message first. If it says non-fast-forward or that the remote contains work you do not have, and you did not rewrite anything, run git pull then push again. If it says the same thing and you did rewrite, for example after an amend or a rebase, use git push --force-with-lease, but only on your own branch. If it says you are not allowed to push to a protected branch, move the commits to a branch and open a merge request. If it says authentication failed or permission denied, the credential is the problem, not the branch. A note says a rejection means nothing was pushed, which is the good outcome. Read the message Git printed "non-fast-forward" and you rewrote nothing git pull then resolve anything that conflicts, and push "non-fast-forward" after an amend or rebase git push --force-with-lease your own branch only; never a shared one "not allowed to push to protected branch" nothing was pushed. Give the commits a branch: git branch <name> ; git reset --hard origin/main "Authentication failed" or "Permission denied" the credential, not the branch: token expired, key not loaded, or no access to the project A rejected push means nothing was pushed. Whatever is wrong, it is still only on your machine. Do not follow the "git pull" hint after rewriting: it merges the old commits back in. Use the lease-checked force. If --force-with-lease is refused as "stale info", a colleague pushed. Fetch, look at what arrived, then decide.
Four messages, four different answers. In every case, nothing was pushed.

Rejections in detail are lesson 7.6, and forcing safely is lesson 12.8.

8. Which undo rewrites history?

Decision guide: which undo rewrites history? Two columns. On the left, safe on shared branches: git revert adds an undo commit; git restore discards your edit; git restore --staged unstages while keeping the edit; git stash parks and restores work; and any new commit is always safe. On the right, rewrites history and is only for commits nobody else has: git commit --amend replaces the last commit; git reset in any mode moves the branch; git rebase, including interactive, replays commits with new hashes; git push --force publishes a rewrite; and git filter-repo rewrites everything. Below, the deciding question: has anyone else seen this commit? If yes, use the left column. Notes add that safe means safe for other people, since restore still destroys your own uncommitted work, and that the reflog can recover anything on the right but only in the clone where it happened. Safe on shared branches these add to history, or touch files only git revert <hash> git restore <file> git restore --staged git stash · stash pop git commit adds an undo commit discards your edit unstages, keeps it parks and restores always safe Rewrites history only for commits nobody else has git commit --amend git reset (any mode) git rebase, rebase -i git push --force git filter-repo replaces a commit moves the branch new hashes publishes a rewrite rewrites everything Has anyone else seen this commit? If yes, use the left column. "Safe" means safe for other people. Restore still destroys your own uncommitted work, permanently. Everything on the right gives the affected commits new hashes. The reflog can recover anything on the right, but only in the clone where it happened.
The left column is safe for other people; the right column is only for commits nobody else has.

The comparison is lesson 12.3, and the dangerous-commands list is lesson 12.9.

The two questions behind all of them

Almost every guide on this page reduces to one of two questions:

Question Decides
Has this been pushed where other people can see it? Whether you may rewrite, or must add a commit
Is it committed? Whether Git can recover it at all

If you remember nothing else from this page, remember those. Everything above is the detail of applying them.

Related