Git is a version-control tool for project files. GitHub is a service that hosts Git repositories and supports collaboration. They are related, but not interchangeable. You can use an assistant to operate Git while learning to recognize what is being saved, where it lives, and how a change reaches the version other people use.
What you will leave with
An understandable project history, one reviewed change, and a demonstrated recovery of a harmless local edit.
Step 1
Find the repository and inspect its state
A repository contains project files and their Git history. Before asking an assistant to change anything, identify the repository, current branch, and files already modified. Someone else's unfinished work may be present. Do not treat every existing change as disposable.
Two useful read-only commands are git status, which summarizes the working state, and git diff, which shows unstaged changes. Ask the assistant to explain their output in ordinary language. You should know which files belong to the task before deciding what to save.
Try this instruction
Inspect this repository without changing it. Tell me the current branch, existing modifications, remote destination, and relevant project instructions. Explain what belongs to my requested task and preserve unrelated work.
You can name the project, branch, and changes that existed before your task.
Step 2
Save one complete change as a commit
Git lets you select changes for the next commit. That selection is called staging. Review both what is selected and what remains outside it, then commit a small, coherent result. Avoid sweeping every changed file into a commit simply because it is convenient.
Write a message that describes the result: add volunteer contact details is more useful than changes. A commit is a local checkpoint; it is not automatically uploaded anywhere. Make checkpoints after meaningful working progress, not after every keystroke.
The commit contains only the intended change and has a message you will understand later.
Step 3
Know what a push makes remote
A remote is another location for the repository, commonly GitHub. Pushing sends commits there. Inspect the destination and repository visibility before the first push. A public repository can expose included content to everyone, so review the file list carefully.
Use ignore rules for files that do not belong in source history, including local secret configuration. Ignore rules do not erase something already committed. If a credential was exposed, revoke or rotate it and address the exposure; deleting the visible line alone is not sufficient.
The remote and visibility are correct, and the files being shared contain no secret values or unintended private material.
Step 4
Use a branch for the next improvement
A branch gives a proposed change its own line of work. Make a small improvement there, then compare it with the intended base branch. On GitHub, a pull request presents that comparison for discussion and review before merging.
Read the diff and test the behavior, even if AI wrote the change. Ask what was checked and what was not. A green automated check is evidence about that check, not a guarantee that every user task works. Keep the change narrow enough to understand.
Try this instruction
Make [one improvement] on an appropriate branch. Keep the change focused. Show the diff, run the checks relevant to this behavior, and report failures or limits. Preserve unrelated work and explain how the change will reach the main version.
You can describe the before-and-after behavior, inspect the diff, and reproduce the relevant check.
Step 5
Give parallel work separate space
Two agents editing the same files can collide. Assign one writer per file or output when possible. For independent coding changes, a Git worktree provides another checkout with its own project files while sharing repository history.
A worktree is useful isolation for edits, not a separate database, hosting account, or security sandbox. Agents still need clear tasks and compatible interfaces. Choose one owner to integrate the changes and run the combined checks. More branches do not remove the need to coordinate.
Each change has an owner and a clear integration plan; shared external resources are identified.
Step 6
Recover without erasing other work
Begin a recovery by inspecting the current state and identifying the last known working version. Preserve unfinished work before applying a broad restore or reset. The right operation depends on whether a change is uncommitted, committed locally, or already shared.
Practice on one harmless paragraph in a local file. Ask the assistant to show the difference, restore only that paragraph, and verify unrelated changes remain. For a shared change, discuss a new reversing commit rather than casually rewriting history. Remember that Git tracks project files; it does not automatically back up database records or external service state.
The practice paragraph is restored, unrelated work remains, and you can explain what Git did and did not recover.
When you get stuck
The assistant wants to discard all local changes
Inspect and preserve them first. Require a narrow recovery plan that identifies exactly what would be lost.
Your commit is missing from GitHub
Check whether it is only local, which branch contains it, and whether you pushed to the intended remote.
A merge reports conflicts
Read both changes, decide the intended combined behavior, resolve deliberately, and test. Do not pick a side blindly.
Terms explained
- Commit
- A recorded checkpoint in the local repository history.
- Stage
- Select changes to include in the next commit.
- Push
- Send local commits to a remote repository.
- Pull request
- A proposed change presented for comparison, discussion, and review.
- Merge
- Combine one line of development into another.
Sources and further reading
The workflow and templates are teaching guidance. The sources below support the underlying tools and concepts; product setup and availability can change.
Take it into your next task
Your completion checklist
0 / 6 checked
Checks are saved on this browser. Mark them only after you inspect the evidence. These are your checks, not an automated certification.