You may understand every word in “the build passed, but the release is blocked” and still miss the message. In a software team, familiar English words often have specific technical meanings. This guide explains the vocabulary you need to follow development work, give a clear progress update, and discuss code politely.
Start with repository, branch, commit, pull request, build, test, and release. Learn them in phrases such as “commit a change,” “review a pull request,” and “deploy to production,” then explain what is finished, what still needs checking, and what is blocking progress.
What's your English level?
Take the test and get your certificate!
Code and Version Control Vocabulary
Source code is the text programmers write to describe what software should do. Version control tracks changes to project files over time. Git is a version control tool; GitHub is a platform where teams can host repositories and collaborate.
| Term | Meaning and example |
|---|---|
| Repository / repo | A collection of project files and their version history. “The setup instructions are in the repo.” |
| Branch | A separate line of development. “I created a branch for the search feature.” |
| Commit | A recorded snapshot in version history; also the verb for recording it. “I committed the validation change.” |
| Push | Send local commits to a remote repository. “I pushed my changes so you can review them.” |
| Pull request / PR | A proposal to review and integrate changes. “The PR is ready for feedback.” |
| Merge | Combine changes from one line of development into another. “We merged the fix into the main branch.” |
These terms describe related but separate actions. Committing locally does not automatically share your work with colleagues, and opening a PR does not mean the changes have been merged. GitHub’s introductory workflow shows how branches, commits, and pull requests fit together.
A diff shows differences between versions. A merge conflict occurs when competing changes cannot be combined automatically and need a decision. Say “There is a merge conflict in the settings file,” rather than the vague “Git is broken.” These terms also appear in the GitHub glossary.
Builds, Tests, Deployments and Releases
Writing code is only part of delivering software. A team also needs to check the change and make the intended version available in the right place. The following distinctions help you avoid saying that something is ready before the necessary work is complete.
| Term | Meaning in a team update |
|---|---|
| Build | The process of preparing software from source files, or its output. “The build failed” describes a process result; “test this build” refers to an output. |
| Test | A check of software behaviour. “The test passed” means its conditions were met, not that the entire product has no bugs. |
| Bug / defect | A fault in the software. “This change fixes the duplicate notification bug.” |
| Regression | A change that causes previously working behaviour to fail. “We added a test to catch this regression.” |
| Deploy | Put a software version into a target environment. “We deployed the change to staging.” |
| Release | A version made available for use, or the act of making it available. “The release includes the new export option.” |
Staging usually refers to an environment for checking changes before production. Production is the live environment serving real users. A deployment to staging therefore does not mean that customers can use the feature.
Teams sometimes use deploy and release differently. A feature may be deployed but remain disabled for users. If a colleague says “It is released,” ask “Is it available to users, or only deployed?” when that distinction matters.
Understand automated checks
CI stands for continuous integration. Teams often use automated workflows to build and test changes as they are integrated. GitHub’s Actions documentation describes workflows that automate tasks including builds, tests, and deployments.
“CI is failing” means one or more checks in that process have failed. It does not identify the cause by itself. A useful follow-up is “Which check failed, and what does the error say?”
Give a Clear Team Progress Update
A useful update identifies completed work, the next action, and any obstacle. A blocker prevents a task from progressing. A dependency is something the work relies on, such as another team’s change or a software package.
Yesterday I implemented the export button and added tests. The PR is ready for review. Today I will address feedback and check the result in staging. Deployment is blocked because we are waiting for the updated service configuration.
Implement means turn a planned behaviour into working code. Address feedback means respond to comments, often by making changes or explaining a decision. “Ready for review” describes a review stage; it does not promise that the feature is ready for customers.
Choose verbs that show the actual stage
Use “I am investigating” when you are still finding the cause. Use “I have identified the cause” when you have evidence, and “I have implemented a fix” when the change is written. Follow that with what remains: “The fix still needs testing.”
Compare “It is done” with “The code is merged, but deployment is scheduled for tomorrow.” The second sentence removes uncertainty without needing a long explanation. If the timing depends on another action, say “I expect to finish after the review” rather than giving an unconditional promise.
For language used when reporting a user-facing fault, our IT support vocabulary guide covers error messages, reproduction steps, and support tickets.
Use Clear, Respectful Language in Code Reviews
A code review is an examination of proposed code changes. The author writes the change; a reviewer evaluates it. GitHub reviews can include comments, approval, or a request for changes, as described in its review documentation.
Good review questions identify the behaviour that concerns you. Instead of “This is wrong,” try “What happens if the list is empty?” Instead of “Bad name,” write “Could we rename this variable to make its purpose clearer?”
Reviewer: Could we add a test for an empty response? That case does not seem to be covered.
Author: Good point. I have added that test and pushed another commit.
Reviewer: Thanks. One optional suggestion: could we simplify the condition?
Author: I would prefer to keep the separate checks because they produce different error messages.
Reviewer: That makes sense. No further comments from me.
An edge case is an unusual or boundary situation that may need special handling. A refactor changes the internal structure of code while aiming to preserve its observable behaviour. “Could we refactor this function?” therefore suggests restructuring, not necessarily adding a feature.
Separate requirements from preferences. “This must be fixed before merging because it loses data” is a blocking concern. “Optional suggestion: use a clearer name” communicates that the point is not intended to block the change.
Practise Software Development Vocabulary
Complete each sentence with one of these words: branch, review, regression, staging, blocker. Read the finished sentences aloud so that you practise useful phrases as well as definitions.
- I created a new ______ for the notification feature.
- The PR is ready for ______.
- The update introduced a ______: the previously working export now fails.
- We are checking the change in ______ before production.
- The missing approval is a ______ because deployment cannot proceed without it.
Answers: 1. branch; 2. review; 3. regression; 4. staging; 5. blocker.
Rewrite an unclear update
Unclear: “I did the feature. There is a problem.”
Clearer: “I implemented the filter and opened a PR. One test is failing when the search returns no results. I am investigating that case before requesting another review.”
Now write your own three-sentence update about a small project. Name the completed action, the current state, and the next step. Use only terms that help your listener understand what is happening.
Frequently Asked Questions
Is a commit the same as a push?
No. A commit records a snapshot in version history. A push sends commits to a remote repository, so local commits can exist before they are shared.
Does “merged” mean “live”?
Not necessarily. Merged describes changes being integrated into another branch. Whether those changes reach users depends on the project’s build, deployment, and release process.
Should I say “codes” or “code”?
When referring generally to software instructions, code is normally uncountable: “I wrote some code” or “This code needs review.” Use “lines of code” for a count. “Error codes” is correct because it refers to separate identifiers, not source code generally.
How can I learn these terms without being a programmer?
Follow one imaginary change from a new branch through review to release. At each stage, write a short sentence about what has happened and what remains. For more general technology terms, start with our technology and internet vocabulary guide.
