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. |
