How code ships
Every team runs the same assembly line to get a change from someone laptop to your customers. Once you can read it, the standup stops sounding like a foreign language.
Software does not go live the moment it is written. It travels a fixed path of steps, and Git tracks every change through it. Nobody edits the shared, live code directly; they propose changes that flow down the line and get checked on the way.
Follow one feature, "Add bKash at checkout", from start to live.
- BranchThe engineer makes a private copy of the code to work in, so main stays stable while bKash is built.
- CommitThey save their progress as a labelled checkpoint with a short note on what changed.
- PushThey upload the branch to the shared server so it is backed up and visible to others. Still not merged, still not live.
- Pull requestThey formally ask for their change to be reviewed and merged. This is the gate before anything joins the shared code.
- ReviewAnother engineer reads the change, asks for fixes, and approves. Cheap bugs are caught here.
- MergeThe approved change joins main, the shared codebase. It is now part of the product, though not necessarily live yet.
- BuildAutomated steps compile the code and run the tests. If this goes red, nothing ships.
- DeployThe built code is placed onto the production servers.
- ReleaseThe feature is turned on for users, often gradually. Deploy puts the code there; release makes it visible.
Two confusions worth clearing up: pull (download the latest) is not a pull request (please review and merge my change), and deploy (put the code on the servers) is not release (turn it on for users).
- "It is in review."
- The code is written and waiting for another engineer to approve it. Not live, and it can still change.
- "The build is failing."
- An automated check went red. Until it is green, nothing new can ship. This blocks releases.
- "There is a merge conflict."
- Two people changed the same lines and Git cannot combine them automatically. Someone has to reconcile it by hand, a short delay.
- "We reverted it."
- A change that shipped caused a problem, so they undid it to get back to the working version. Expect a retry later.
- "It is in main but flagged off."
- The code is merged and deployed but switched off for users. It can be turned on instantly when ready, with no new deploy.
Advance the bKash feature one stage at a time. Each stage shows what the engineer says and what to ask.
- >
- >
- >
- >
- >
- >
- >
- >
At standup, day 1
"Branched off main to start the bKash work."
What it means: Nothing yet. Work has started in isolation and touches nobody else.
Do not: Do not ask when it is live. It has not left the engineer machine.
Scenario: the build fails right after merge, on Thursday.
The change is in main but the build is red, so it will not deploy. Nothing reaches users until the build is green again. For a Friday release that means the fix has to land and pass first; if it cannot, you either slip the date or ship with bKash flagged off. It does not mean the whole product is broken, only that this pipeline is paused.
- clone
- Make a local copy of a repository to work on. Repository
- branch
- Start an isolated line of work off the main code. Git and version control
- commit
- Save a labelled checkpoint of your changes. Git and version control
- push
- Upload your commits to the shared server. Git and version control
- pull
- Download the latest changes from the shared server. Git and version control
- merge
- Combine one branch into another, usually into main. Pull requests and code review
- revert
- Undo a change by adding the opposite change. Rollback
- build
- Compile the code and run the automated tests. CI/CD
- deploy
- Put the built code onto the servers. Deployment and releases
- release
- Turn a deployed feature on for users. Feature flags
- rollback
- Return to the previous known-good version fast. Rollback
- hotfix
- Push an urgent fix straight to production. Hotfix