Did you know? A student can proudly announce “I saved the code!” while their teammate still cannot see the change. The code may be saved in an editor, recorded as a Git commit on one laptop, or sent to a shared repository with push. These are different events. A fourth word—pull—is about receiving and integrating changes, not sending them.
Vocabulary matters because commit records a chosen snapshot in a local Git repository, push sends local commits to a remote repository, and pull retrieves and integrates changes from a remote branch. Understanding these verbs helps a school coding group explain why one person’s work has not reached another computer, avoid unnecessary overwriting and ask better troubleshooting questions.
The useful question is not “Did you save?” but “Where did the change go?”
Imagine a three-student computing club project to build a simple school-library book finder. Aria writes a search function on her laptop. Ben edits the page layout on his. Chen is preparing screenshots for their presentation. Aria says she has finished. Ben opens the team’s shared repository and cannot find the search change. Has Aria lost her work? Perhaps not. The group may simply be describing three different stages with the one word save.
There is a clear progression: a file is saved in a working folder; selected changes are staged; a commit records them in that repository’s local history; a push tries to update the remote branch; another learner must fetch or pull to see that remote history locally. A hosting service may offer a separate review-and-merge process. Those events do not collapse into one button.
Commit: record an explainable local checkpoint
A commit is a recorded snapshot of staged changes in a Git repository, together with information such as its author, message and relation to previous commits. It creates a checkpoint the learner can inspect in the history. A commit does not automatically send the work to GitHub or another remote host.
Think of a student making a science notebook entry: “I changed how we label missing sensor values.” The Git equivalent should describe a coherent change. A good commit message says what was done, not merely “stuff” or “final final”. In our invented project, Aria might use Add case-insensitive book title search. The message helps Ben see what changed without reading every line first.
The word family includes commit, committed, committing; relevant collocations include make a commit, commit history, commit message, staged changes, local repository. In ordinary English, commit may mean a promise or dedication. In Git, it names a specific repository operation. The context is technical, not moral.
Why saving a file does not always create a commit
A code editor can save the file immediately, yet Git will show it as modified and uncommitted. Git does not automatically capture every edit as a new commit. A student generally needs to decide which changes belong together, stage them, then commit. Untracked new files may also need to be staged. In a classroom, the difference teaches responsibility: decide what you mean to submit before recording it.
Push: make a local change available in a remote repository
A push transfers appropriate local commits and updates a remote branch when allowed. If Aria committed her search function only on her laptop, Ben’s remote view can remain unchanged. When she pushes to the agreed remote branch, Ben can retrieve those changes. A successful push confirms that the remote branch was updated—not that every teammate has pulled it, every test has passed, or the final application is running live.
A remote repository is commonly hosted on a service such as GitHub, but Git does not require GitHub specifically. The remote’s name origin is a conventional label, not a special synonym for the internet. A branch is a line of development. School groups may choose different branch arrangements; a teacher or project leader should agree on them before students follow command examples.
Collocations: push a branch, remote repository, push rejected, upstream branch, remote tracking. In a normal conversation, pushing is physical. In version control, it means sending repository history. A precise status update might be, “I committed locally, but I have not pushed my branch yet.”
Pull: bring remote changes into a local branch
A pull normally combines two broad steps: first Git fetches updated information from a remote, then it integrates the relevant history into the current branch. Depending on the command options and configuration, that integration may involve a merge, a rebase or fast-forward behaviour. Saying “pull always overwrites my files” is incorrect, and saying “pull is only a download” misses the integration stage.
Suppose Ben wants Aria’s completed search function. If she successfully pushed to the branch they agreed on, Ben can retrieve it. Before updating his own work, he should check his working tree and follow the group’s branch process. Git may refuse to proceed when his local changes could be overwritten or may require him to resolve divergent work. A safe response is to read the message rather than repeatedly trying unrelated commands.
Related vocabulary: fetch retrieves remote history without automatically integrating it into the current branch; pull retrieves and integrates according to the chosen strategy; merge combines histories; a conflict is a situation that needs human decisions about competing changes. These words explain distinct jobs.
A worked project narrative: four status sentences that are all different
This is an invented teaching scenario, not a record of real eduKate students or an official school programme. The group is building the imaginary library-book finder. They use a shared code repository with a simple agreed branch workflow under adult or teacher supervision.
- Monday 15:00 — “I saved the file.” Aria changed search.py in her working folder. The code exists on her laptop but is not necessarily recorded in a commit.
- Monday 15:10 — “I committed the new search.” Aria staged the intended file and made a local commit. It is in her local repository’s history, not necessarily in the shared remote.
- Monday 15:15 — “I pushed my branch.” The shared remote now has the new commits on the relevant branch, assuming Git confirmed a successful push.
- Monday 15:25 — “I pulled the agreed branch and ran our checks.” Ben has brought appropriate remote changes into his local branch and then tested whether the project still behaves as expected.
The order describes one plausible group workflow, not the only legitimate Git process. In another project, code is pushed to a feature branch and reviewed in a pull request before it is merged. The reviewer may test the change and ask for revisions. No one should treat “pushed” as a synonym for “reviewed”, “approved” or “deployed”.
A small command-line reading exercise, not an instruction to modify an important repository
Older learners may meet short command examples like these. Read them first as English and discuss their effect. Use only a disposable practice repository with a teacher or experienced adult; do not copy them into a shared production project without understanding its policies.
git status
git add search.py
git commit -m "Explain missing book results"
git pushRead it in order. git status lets a learner inspect local state. git add search.py stages changes from the chosen path as of that operation. git commit -m records a checkpoint with a message. git push attempts to send commits according to the repository’s branch and remote configuration. The final command can fail or ask for more information; never claim it automatically succeeded.
Students can explain the commands without running them: “Check what changed; choose what to include; record the chosen change; try to share it with the remote.” This verbal rehearsal is helpful before working with a graphical Git client whose buttons use slightly different labels.
Notice what is not present: there is no universal button that means “save, stage, commit, push, review and publish all at once”. Some graphical tools offer combined shortcuts, but the underlying states are still distinct. Understanding the state makes those shortcuts safer to use.
Why Git status is a better answer than guessing
A teammate asks, “Why isn’t my work showing up?” One student immediately says, “Push again!” Another checks the evidence. Did the file save? Is it untracked? Was it staged? Is the commit present locally? Was the push rejected? Are the students looking at the same branch and remote? Did the other student fetch or pull? This is a debugging problem driven by vocabulary.
The first student has a guess; the second has a diagnostic tree. The word status is useful because it directs attention to observable state. A clear report might be: “My working tree has two modified files, no new commit, and no push attempted.” That sentence invites help much faster than “Git is broken.”
The coding concepts in this article are distinct from eduKate’s published guide Debugging Student Code by Distinguishing Syntax, Runtime and Logic Errors. That neighbouring article addresses errors in program behaviour. Here the question is how changes travel between local and shared project histories.
When a push fails, read the reason before acting
A push can be rejected when the remote branch contains work not yet integrated into the local branch, or when repository permissions and branch rules prevent the update. The exact remedy depends on the situation. Students should not respond by forcing a push to a shared branch; a force push can replace branch history in ways that confuse or lose teammates’ work.
A cautious group can stop, record the complete error message without sharing passwords or tokens, check the branch names, and ask the teacher or maintainer which integration route is appropriate. Pushing is a permission-sensitive operation. If the project is not the student’s repository, they may need review access or a feature-branch workflow instead of direct push permission.
Similarly, merge conflict does not mean two students have done bad work. It can mean Git cannot safely choose how to reconcile changes to the same text or history automatically. Humans need to decide which content belongs in the final version. A team can reduce confusion by committing focused changes, discussing files before editing the same sections, and reviewing the differences together.
Pull request is not pull
On platforms such as GitHub, a pull request is a proposal to merge changes from one branch into another. It provides a place to discuss, review and run checks on the proposed change. Opening a pull request is not the same as running git pull. It neither guarantees approval nor merges the work automatically just because a request exists.
The similar names create a frequent language trap. A precise school-team message is, “I pushed my feature branch and opened a pull request for review.” That sentence reports two actions. A separate message would confirm the review decision and whether it was merged. For collaborative projects, naming these states supports fairness: nobody can claim a contribution was accepted merely because it was proposed.
A teacher’s ten-minute exercise without any private code
- Minute 1–2: read four invented chat messages: “saved”, “committed”, “pushed”, “pulled”. Place them on a timeline.
- Minute 3–4: give students cards labelled working file, local history, remote branch. Ask where the code exists after each action.
- Minute 5–6: present Ben’s problem: “I cannot see Aria’s change.” Students ask three evidence-seeking questions rather than offer commands immediately.
- Minute 7–8: introduce a separate pull request card for a review workflow and ask why it is not a synonym for pull.
- Minute 9–10: each learner writes one accurate status update and one helpful next question for a teammate.
This activity needs no Git account, passwords, public repository, API token or student identity data. For beginners, paper cards are enough. Secondary learners who are ready can repeat the exercise inside a disposable practice repository, with explicit permission and a clear shared-branch policy.
Transfer to English, Mathematics, Science and adulthood
English: precise verbs distinguish events. “I changed”, “I recorded”, “I shared”, and “I received” describe different actions and support evidence-based communication. The same habit improves instructions and school reports.
Mathematics: think in states and transitions. At time A the change exists in a working folder; at B it is recorded locally; at C the remote has the updated branch. A state diagram makes the workflow easier to test. The diagram is a model, not a claim that all repositories follow one path.
Science: a laboratory group may work with code that processes measurements. Recording small, explainable changes helps another learner repeat an analysis, but version control alone does not prove that a scientific result is correct. They still need data quality checks, units, source records and reproducible methods.
Careers and adulthood: software teams use version control to manage collaborative change. People working in research, design, data and technical writing can benefit from understanding when a change is local, shared, proposed or approved. The concept is broader than mastering a single website’s interface.
For a wider language foundation, see eduKate’s English Across School Subjects. The point is not to turn every child into a programmer overnight. It is to show how one exact verb can prevent an entire group from acting on the wrong assumption.
Five common misconceptions, each with a practical repair
- “Save and commit are identical.” Saving writes a working file; committing records staged changes in repository history. Repair: ask whether the change appears in the latest commit.
- “My commit is visible to everyone.” It may exist only locally. Repair: identify the branch and remote, then check whether the intended push succeeded.
- “Pushing means the new website is live.” A push updates repository history, not necessarily a deployment. Repair: distinguish repository state, review, integration and release.
- “Pull only downloads.” Git pull also integrates according to settings and the situation. Repair: inspect local work and choose a safe workflow before pulling.
- “A pull request means the same as git pull.” One proposes changes for review on a hosting platform; the other retrieves and integrates remote changes in a Git repository.
Diagnostic questions before a group reports a problem
Try asking a student: What do you mean by saved? Which files changed? Did you stage the right path? Did you create a commit? Which branch are you on? What remote did you use? Was the push successful or rejected? Has your teammate fetched or pulled the expected branch? Is a pull request waiting for review? Which step can you verify rather than infer?
A useful parent question is less technical: “Who can see the work right now, and what makes you sure?” Encourage the learner to answer without disclosing passwords, access tokens, private repository addresses or classmates’ personal information. That is good digital citizenship as well as good engineering.
Retrieval and application: test your understanding tomorrow
- Aria edits and saves search.py, then closes the editor. Is a commit guaranteed to exist? Why?
- Ben sees that Aria’s commit is on her laptop but not on the shared remote. Which verb describes the missing sharing step?
- Chen wants updates from the remote in his local branch. Which action may fetch and integrate them?
- A teacher says, “The code has been pushed, so the app must already be deployed.” What is wrong with that inference?
- Two students edit the same lines and encounter a merge conflict. Does the word conflict prove that one student is at fault?
- A learner pushed a feature branch and opened a pull request. What further decision is still needed before calling the change merged?
Answer check: saving is not the same as committing; a push shares appropriate commits to a remote; pull may fetch and integrate remote changes; deployment is a separate process; a conflict requires reconciliation, not blame; a pull request still needs whatever review and merge decision the repository requires. If any answer felt shaky, return to the project timeline and name where the change exists after each event.
Frequently asked questions
Do primary-school children need to memorise Git commands?
Not usually. The age-appropriate goal here is to understand a simple collaboration story and how precise words describe actions. A paper exercise can teach local, shared, saved and reviewed without introducing command-line complexity.
Should secondary students always pull before they start?
There is no universal sequence for every situation. Checking the branch, the working tree and the team’s agreed workflow is more reliable than repeating a rule blindly. A beginner should follow their project’s instructions or ask a maintainer before operations that integrate divergent work.
If Git says there is nothing to commit, does that mean my teammate has the code?
No. That message concerns the local state Git is inspecting. It does not prove a successful push, that the teammate is on the same branch, or that the work was reviewed or released.
Can someone recover every mistaken change from a commit?
Git histories can help recover earlier versions when the relevant objects and history remain available, but recovery is not guaranteed in every scenario. A commit is not a replacement for a properly managed backup, nor is a public repository appropriate for secrets.
What should a student do when instructions conflict?
Do not guess or force an update. Capture the non-sensitive status and error information, confirm the agreed branch and ask the teacher, team lead or maintainer to choose the correct workflow. Explaining the state precisely is already meaningful progress.
Authoritative references and a next action
Git’s primary documentation explains remotes, fetching and pushing in Pro Git and the precise behaviour and options of git pull. GitHub’s pull request reference describes proposals, reviews and merging. These documentation sources describe the tools; the school scenario above is illustrative.
Try this now: in a classroom discussion, finish four sentences accurately: “I saved __.” “I committed __.” “I pushed __.” “I pulled __.” Then add a fifth: “My teammate can verify the change by __.” A useful vocabulary lesson ends when the whole team can describe the same state without guessing.