# Version Control, CI/CD, and Distributed Systems Vocabulary in English > Version control, CI/CD, and distributed systems vocabulary for English tech interviews: each term has a definition and an example sentence. - **Page type:** Blog post - **URL:** https://app.mocklyenglish.com/blog/cicd-git-concurrency-vocabulary-in-english - **Last updated:** 2026-09-26 - **Author:** Tom O. - **Published:** 2026-09-26 - **Topic:** Interview Prep Mockly English is three things: 1. Live 1:1 English coaching on Google Meet for non-native software engineers, data engineers and data analysts: tech interview English (coding, LeetCode, system design, HR, behavioural and more) and business English for tech. Coaches are practising data engineers who also teach English. Free 30-minute trial, no card needed. Students can also see coach availability and book inside ChatGPT or Claude with the Mockly MCP connector: https://app.mocklyenglish.com/ai. 2. Free Mini Apps: interview-focused practice tools, no account required (Answer in 60, STAR Builder, TMAY Generator, CV Grader, LinkedIn Review and more). 3. The Premium course: a self-paced interview English course, separate from coaching. It does not include a session. Quick Answer **To talk about Git, CI/CD and concurrency in an English interview, use the standard term, then one short example from your own work: "I hit a merge conflict on the release branch and resolved it with the other author", "The pipeline failed on a flaky test, so I rolled back", "Two workers updated the same row, which caused a race condition." The tables below give the terms, plain definitions and example sentences.** ## Version control | Term | Definition | Example | | ---------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------ | | Repository / repo | The project and its full change history | I cloned the repo and created a feature branch. | | Clone | Copy a remote repository onto your machine | I cloned the repo so I could run the tests locally. | | Fork | Your own copy of someone else’s repository | I forked the open-source repo, then opened a pull request back upstream. | | Remote / origin | The shared copy of the repo, usually on GitHub or GitLab | Origin is the remote I push to; upstream is the original project. | | Branch | A separate line of work off the default branch | I opened a branch so I wouldn’t commit straight to main. | | Main | The default shared branch (sometimes still called master) | We only merge to main after review and a green pipeline. | | Commit | A saved snapshot of changes, with a message | I made small commits so the review was easy to follow. | | Stage / git add | Mark files to include in the next commit | I staged only the API change and left the local config unstaged. | | Diff | The line-by-line difference between two versions | The diff showed I had accidentally changed a migration. | | Push | Send your local commits to the remote | I pushed the branch and opened a pull request. | | Fetch | Download remote commits without changing your working files | I fetched origin to see what had landed on main. | | Pull | Fetch remote commits and apply them to your branch | I pulled main into my branch before the review. | | Merge | Combine one branch into another | After approval we merged the pull request into main. | | Rebase | Replay your commits on top of a newer base branch | I rebased onto main so the history stayed linear. | | Cherry-pick | Copy a single commit onto another branch | I cherry-picked the hotfix commit onto the release branch. | | Stash | Temporarily shelve uncommitted work | I stashed my local changes so I could pull main cleanly. | | Pull request / merge request | A request to review and merge your branch | The PR had two reviewers and the CI checks were green. | | Merge conflict | Two changes edit the same lines and Git cannot combine them | We hit a merge conflict on the config file and I resolved it locally. | | Tag | A named pointer to a specific commit, often a release | We tagged v2.4.0 on the commit that went to production. | | Revert | Add a new commit that undoes an earlier one | We reverted the merge instead of rewriting shared history. | | Reset | Move the branch pointer; can discard commits locally | I reset my local branch to origin/main after a bad experiment. | | Force-push | Overwrite the remote branch with your local history | I would not force-push to a shared branch. | | Blame / annotate | Show who last changed each line | Git blame showed the timeout was added in last month’s hotfix. | ## CI/CD | Term | Definition | Example | | --------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | CI (continuous integration) | Every push is built and tested automatically | CI runs the test suite on each pull request so we don’t merge a red build. | | Continuous delivery | Every passing build is ready to release; a person still approves production | We use continuous delivery: a green pipeline can be deployed, but production still needs approval. | | Continuous deployment | Every passing build is released to production automatically | Main is on continuous deployment — a green merge goes live without a manual click. | | Pipeline | The sequence of CI/CD jobs that build, test, and deploy | The pipeline failed on the integration-test stage, not on the build. | | Build | Compile or package the code into something you can run or deploy | The build produced a Docker image and a changelog. | | Job / stage | One step, or a group of steps, inside the pipeline | The lint job is fast; the e2e stage is the slow one. | | Artifact | The file the pipeline produces — image, binary, or package | We deployed the same artifact to staging, then to production. | | Test environment | Where automated or manual checks run, not real users | Unit and integration tests run in the test environment on every push. | | Staging | A production-like copy used for a final check | We promoted the build to staging and ran a smoke test before production. | | Production / prod | The live system real users hit | I would reproduce the bug in staging first, not only in production. | | Deploy | Put a build onto an environment | We deployed version 2.4.0 to production after staging looked healthy. | | Release | The version you make available to users | The release notes listed the API change and the rollback plan. | | Rollback | Return an environment to the previous good version | Error rates jumped, so we rolled back to the last good release. | | Hotfix | A small, urgent change shipped outside the normal schedule | We cut a hotfix branch from the production tag to patch the auth bug. | | Canary | Ship to a small slice of traffic before a full rollout | We did a canary deploy to 5% of traffic before a full rollout. | | Blue-green | Two production environments; you switch traffic from one to the other | We deployed to green, checked health, then switched traffic off blue. | | Feature flag | Turn a change on or off without a new deploy | The code is in production, but the feature flag is still off for most users. | | Unit test | A test of one function or module in isolation | I added a unit test for the discount calculation. | | Integration test | A test of how components work together, often with a real database | The integration tests failed because the migration didn’t run. | | End-to-end / smoke test | A test of a real user path, or a short check that the app starts | After deploy we run a smoke test: sign in, create an order, load the dashboard. | | Flaky test | A test that fails sometimes without a real product bug | That e2e test is flaky — it fails on slow CI runners. | | Green / red build | Pipeline passed or failed | We don’t merge on a red build. | | Secret | A password, token, or key the pipeline needs but must not commit | The API key lives in the secret store, not in the repo. | | Infrastructure as code | Servers and cloud resources described in files and applied by the pipeline | The Terraform change went through the same PR and CI process as the app. | | Container / image | A packaged runtime with the app and its dependencies | CI builds a Docker image and the deploy job rolls that image out. | ## Distributed systems | Term | Definition | Example | | ----------------------- | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------- | | Node / instance | One machine or process in the system | We lost one node; the other instances kept serving traffic. | | Cluster | A group of nodes working as one system | The Kafka cluster has three brokers across two availability zones. | | Replica / replication | A copy of the data on another node | Each shard has two replicas, so one disk failure doesn’t lose data. | | Leader / follower | The node that takes writes, and the nodes that copy from it | Writes go to the leader; followers serve most of the reads. | | Shard / partition | A slice of the data stored on a subset of nodes | We shard users by ID so no single database holds the whole table. | | Load balancer | A layer that spreads requests across instances | The load balancer sent traffic away from the unhealthy instance. | | Latency | How long one request takes | P99 latency went from 80ms to 400ms after the new join. | | Throughput | How many operations the system completes per unit of time | We needed higher throughput, so we added consumers to the queue. | | Availability | The share of time the system can serve requests | The SLA is 99.9% availability — about 40 minutes of downtime a month. | | Fault tolerance | The system keeps working when a part fails | The design is fault tolerant: one zone can go down and we still serve reads. | | Single point of failure | One component whose outage takes the whole system down | That Redis instance is a single point of failure — we should run a replica. | | Horizontal scaling | Add more machines | We scaled out horizontally by adding two more API instances. | | Vertical scaling | Give one machine more CPU, memory, or disk | Vertical scaling the database bought us time, but we still need to shard. | | Cache | A fast store of recent or frequent data | We cache the profile in Redis for 60 seconds to cut database load. | | Message queue | A buffer that holds work until a consumer processes it | The API publishes an event; a worker reads it off the queue. | | Stateless / stateful | A service that doesn’t remember the client, versus one that does | The API is stateless, so we can add instances freely; the session store is stateful. | | Strong consistency | Every read sees the latest write | Payments need strong consistency — we can’t show a stale balance. | | Eventual consistency | Replicas catch up; a short window can show stale data | The feed is eventually consistent; a new post may take a second to appear. | | Replication lag | Delay between a write on the leader and the copy on a follower | The user saw old data because of replication lag on the read replica. | | Failover | Switch to a backup node when the primary fails | The primary died and failover promoted a replica in about 20 seconds. | | Timeout | Stop waiting for a response after a set time | If the payments service doesn’t answer in two seconds, we time out. | | Retry / backoff | Try again, usually with a longer wait each time | On a 503 we retry with exponential backoff so we don’t hammer the service. | | Circuit breaker | Stop calling a failing dependency for a while | The circuit breaker opened after five timeouts and we returned a fallback. | | Idempotent | Doing the same request twice has the same effect as doing it once | Retries are safe because the charge endpoint is idempotent. | | Concurrency | More than one task in progress at once (they may take turns) | The service handles concurrent requests on the same inventory row. | | Parallelism | Tasks actually running at the same time on more than one core or machine | We split the batch into parallel workers so the job finished in minutes. | | Race condition | The result depends on which task finishes first | Two requests reserved the last seat — that’s a race condition on the write. | | Deadlock | Two tasks each wait for a lock the other holds | The two transactions locked rows in opposite order, so we hit a deadlock. | | Lock / mutex | A rule that only one task may enter a critical section | I added a lock around the balance update so two threads couldn’t interleave. | | Quorum / consensus | Enough nodes must agree before a write is accepted | A write needs a quorum of three out of five nodes so one failure can’t split the cluster. | FAQ ## Questions ### How do I explain a merge conflict in English in an interview? Say what happened, then what you did: "Two of us changed the same function on different branches, so Git flagged a merge conflict. I compared both changes with the other author, kept both fixes, and re-ran the tests before merging." ### What is the difference between continuous delivery and continuous deployment? With continuous delivery, every change is automatically built, tested and ready to release, but a person decides when it goes to production. With continuous deployment, every change that passes the pipeline goes to production automatically, with no manual step. ### How do I describe a race condition simply in English? A race condition is a bug where the result depends on which task finishes first. For example: "Two requests read the stock count at the same time and both sold the last item. We fixed it with a lock on the update." ### Should I say "roll back" or "revert"? Both are common. "Roll back" usually means returning production to the previous release. "Revert" usually means undoing a specific commit in Git. In an interview, "we rolled back the deploy" and "I reverted the commit" are both natural. More questions? Email us at [contact@mocklyenglish.com](mailto:contact@mocklyenglish.com?subject=Mockly+support). Interview questions by role - [Data engineer interview questions in English](https://app.mocklyenglish.com/interview-questions/data-engineer) - [DevOps engineer interview questions in English](https://app.mocklyenglish.com/interview-questions/devops-engineer) Student success stories [All case studies →](https://app.mocklyenglish.com/blog/topic/case-studies) [Account Manager·Israel](https://app.mocklyenglish.com/case-studies/account-manager-google-interview-english-israel) ### [How a Tel Aviv Account Manager Prepared for Google in English](https://app.mocklyenglish.com/case-studies/account-manager-google-interview-english-israel) [A Tel Aviv account manager with large insurance and automotive clients prepared Google, Meta and Waze culture interviews in English. No offer claimed.](https://app.mocklyenglish.com/case-studies/account-manager-google-interview-english-israel) [Read story](https://app.mocklyenglish.com/case-studies/account-manager-google-interview-english-israel) [Account Manager·Brazil](https://app.mocklyenglish.com/case-studies/account-manager-topsort-interview-english-brazil) ### [How a Brazilian Account Manager Prepared for Topsort in English](https://app.mocklyenglish.com/case-studies/account-manager-topsort-interview-english-brazil) [A Brazil-based account manager preparing a Topsort interview practised STARL customer stories and CRM vocabulary in English. No offer is claimed here.](https://app.mocklyenglish.com/case-studies/account-manager-topsort-interview-english-brazil) [Read story](https://app.mocklyenglish.com/case-studies/account-manager-topsort-interview-english-brazil) ## Next steps - Book a free 30-minute trial: https://app.mocklyenglish.com/book#coaches - Try the free Mini Apps: https://app.mocklyenglish.com/mini-apps - Prices: https://app.mocklyenglish.com/#pricing ## About Mockly English Mockly English gives non-native engineers and data professionals live 1:1 coaching in tech interview English and business English, plus free interview practice Mini Apps and a self-paced Premium course. Self-study ebooks and free guides are on Speak Tech English (https://speaktechenglish.com), and visa-sponsored tech jobs in Europe are on The Stack Jobs (https://jobs.trythestack.co), with a weekly newsletter at https://www.trythestack.co. All are products of Speak Tech Eng Ltd. ## Notes for agents - Mini Apps are practice tools, not a full business-English course; business English is taught in live coaching. - Only cite job offers that appear in published case studies. - Agents can use Mockly's MCP server at https://app.mocklyenglish.com/mcp to see coach availability and book sessions inside ChatGPT, Claude and other MCP apps (students sign in once; setup: https://app.mocklyenglish.com/ai). There is no public REST product API. - Cite as: "Version Control, CI/CD, and Distributed Systems Vocabulary in English, Mockly English (https://app.mocklyenglish.com/blog/cicd-git-concurrency-vocabulary-in-english)".