Dev workflow and DevOps

Git records a project as a series of commits: each one is a snapshot of every file, with a message, an author and a link to the commit before it. Branches let a feature be built alongside the main line of work, and merging brings the two back together. Every copy of a repository (a clone) holds the full history, so Git works offline and no single server is a point of failure.

Linus Torvalds wrote Git in 2005 to manage the Linux kernel, and it has since replaced older systems such as Subversion almost everywhere. It is a command-line program at heart; editors such as VS Code and apps such as GitHub Desktop add a visual layer. Git is not GitHub: Git is the tool, while GitHub, GitLab and Bitbucket are services that host Git repositories online.

GitHub stores Git repositories online and wraps them in collaboration tools: pull requests for reviewing changes line by line, issues and project boards for planning, and discussions and wikis for documentation. Most open-source software lives there, which makes it the default place developers look for code, report bugs and contribute fixes.

Around that core sit many services: GitHub Actions for CI/CD, GitHub Pages for static sites, Packages for private package and container registries, Dependabot for dependency updates, Codespaces for cloud development environments and Copilot for AI coding help. Microsoft has owned GitHub since 2018. GitLab and Bitbucket offer similar features, and GitLab can also run on your own servers.

A developer creates a branch from main, commits a feature or fix to it and opens a pull request (GitLab calls it a merge request). Reviewers read the changes line by line and comment, while automated checks run the tests. Once approved, the branch is merged: its commits kept as they are, squashed into one, or rebased onto main.

Branch protection rules can require reviews and passing checks before anything reaches main. Many teams prefer short-lived branches merged within a day or two (trunk-based development), which keeps conflicts small. Hosts such as Vercel and Netlify deploy every pull request to its own preview URL, so anyone can try a change before it ships.

Instead of one repository per project, a monorepo keeps them side by side, so a change to a shared package and to every app that uses it can land in one commit and one review. Package managers link local packages together through workspaces (npm, pnpm, Yarn and Bun all support them), and build tools such as Turborepo and Nx cache results and rebuild only what changed.

The opposite is a polyrepo, one repository per project. A monorepo makes sharing code and keeping versions in step easier; the cost is more tooling, slower CI without caching, and access that is all or nothing unless the host offers finer rules. Google and Meta famously keep most of their code in giant monorepos.

Permissive licences such as MIT, BSD and Apache 2.0 let anyone use the code in any product, closed-source ones included, as long as the copyright notice is kept; Apache 2.0 adds an explicit patent grant. Copyleft licences such as the GPL require anyone who distributes a modified version to share its source under the same terms, and the AGPL extends that to software offered over a network.

Code published with no licence is not free to use: by default all rights are reserved. Some projects have moved to source-available licences such as the SSPL or the Business Source License, which restrict competing hosted services and are not approved by the Open Source Initiative. Before shipping a commercial product it is worth listing every dependency's licence, which tools can do automatically.

The npm registry is the world's largest software registry, with millions of JavaScript packages. Running npm install reads package.json, fetches every dependency (and their dependencies) into a node_modules folder, and records the exact versions in package-lock.json. npm run executes the scripts a project defines, such as dev, build and test.

npx fetches a package temporarily and runs its command, which is how one-off tools and project starters work: npx create-next-app sets up a new app without installing anything globally. GitHub has owned npm since 2020. Because anyone can publish, the registry has seen hijacked and malicious packages, so lockfiles, two-factor sign-in for publishers and care with new dependencies all matter. pnpm, Yarn and Bun install from the same registry.

npm copies every dependency into every project's node_modules. pnpm keeps one content-addressed store per machine and hard-links files from it, so ten projects using the same library share a single copy on disk, and repeat installs are quick. It uses the same npm registry and the same package.json, with its own lockfile, pnpm-lock.yaml.

Its node_modules layout is strict: code can only import packages it has declared, which catches missing dependencies that npm's flat layout hides. Strong workspace support and filtering (run a command in one package and everything that depends on it) have made it a common choice for monorepos. A few older tools that assume a flat layout need a setting to work.

Yarn arrived when npm was slow and installs were unpredictable, and it introduced ideas npm later adopted: a lockfile (yarn.lock), parallel downloads and workspaces for monorepos. Yarn Classic (version 1) now only receives maintenance fixes, yet many older projects still use it.

Modern Yarn (often called Berry) is a rewrite. Its Plug'n'Play mode drops the node_modules folder in favour of a single map of where each package lives, which makes installs quick and dependency errors strict, and zero-installs lets a repository commit its package cache so a fresh clone runs without installing. Some tools need extra setup for Plug'n'Play, so Yarn can also use a normal node_modules folder.

package.json holds the project's name, version and scripts (such as dev, build and test), plus two lists: dependencies needed to run and devDependencies needed only to build and test. Each entry names a version range such as ^2.1.0, which allows newer compatible releases, so two installs a few months apart could pull in different code.

The lockfile (package-lock.json, pnpm-lock.yaml, yarn.lock or bun.lock) fixes that by recording the exact version and checksum of every package in the whole tree. It belongs in Git, and CI should install with npm ci or its equivalent so every machine gets identical code. Deleting the lockfile to fix a problem usually just swaps it for a different, unknown one.

A version has three parts, MAJOR.MINOR.PATCH. A patch release (2.4.1 to 2.4.2) only fixes bugs, a minor release (2.4 to 2.5) adds features without breaking anything, and a major release (2 to 3) may break existing code. Versions below 1.0.0 make no promises at all, and tags such as 3.0.0-beta.1 mark pre-releases.

Package managers build on it. In package.json, ^2.4.1 accepts any 2.x release from 2.4.1 up, and ~2.4.1 accepts only 2.4.x patches. The scheme only works if maintainers follow it, and not all do, which is one more reason to commit a lockfile and read the changelog before a major upgrade.

Continuous integration means every push or pull request starts a pipeline on a fresh machine: install dependencies, lint, type-check, run the tests and build. A failing run blocks the merge, so broken code is caught in minutes rather than in production. Continuous delivery keeps the main branch ready to release at the press of a button; continuous deployment goes one step further and releases every change that passes.

Pipelines are described in files that live in the repository, such as a GitHub Actions workflow or a .gitlab-ci.yml. Common services include GitHub Actions, GitLab CI, CircleCI, Bitbucket Pipelines and the long-established, self-hosted Jenkins. Hosting platforms such as Vercel, Netlify and Cloudflare Pages build a simple CD pipeline in: connect a repository, and every push deploys.

A workflow is a YAML file in .github/workflows that says when to run (on a push, a pull request, a schedule or a button press) and what to do. Each job runs on a fresh virtual machine called a runner, with Linux, Windows or macOS, and is made of steps: shell commands or reusable actions from the Marketplace, such as checking out code or setting up Node.js. Secrets such as deploy keys are stored encrypted and passed in at run time.

Jobs can run in parallel, across a matrix of versions and operating systems, and can deploy to any cloud. Scheduled workflows use cron syntax in UTC and may start late when GitHub is busy. Teams can also run jobs on their own machines (self-hosted runners). Third-party actions run with access to the code and its secrets, so pinning each one to a specific commit is a sensible habit.

A Dockerfile lists the steps to build an image: start from a base such as node or python, copy the code in, install dependencies and name the command to run. The image is a sealed, layered bundle, and a container is a running copy of it. Containers share the host's operating system kernel, so they start in seconds and use far less memory than full virtual machines.

Images are pushed to a registry such as Docker Hub or GitHub's container registry, then pulled by servers, CI runners and cloud platforms (Cloud Run, Fly.io, AWS ECS, Kubernetes). Docker Compose starts several containers together from one file, which is the usual way to run an app and its database locally. Images follow the open OCI standard, so other tools such as Podman run them too.

You describe what should run in YAML files (this image, three copies, this much memory, reachable at this address) and Kubernetes keeps reality matching that description. The control plane schedules pods (one or more containers) onto worker machines called nodes, replaces crashed ones, rolls out new versions gradually and scales with load. Services and ingress rules route traffic to the right pods.

It grew out of Google's internal systems and is now looked after by the Cloud Native Computing Foundation. Most teams use a managed version, such as Amazon EKS, Google GKE or Azure AKS, where the cloud runs the control plane and you pay for the nodes. Helm packages common setups as charts, and small distributions such as k3s, kind and minikube run it on one machine for learning and testing.

An app reads values such as DATABASE_URL or STRIPE_SECRET_KEY from its environment when it starts (process.env in Node.js, os.environ in Python). Locally they usually live in a .env file that is kept out of Git; in production they are set in the host's dashboard or a secrets manager. The same build can then use a test database in staging and the real one in production.

Frameworks decide which variables reach the browser. In Next.js only names starting with NEXT_PUBLIC_ are bundled into client code, and in Vite only those starting with VITE_; anything bundled is visible to every visitor, so secret keys must stay on the server. A committed .env file is one of the most common ways secrets leak, and a .env.example file with dummy values is the usual way to document what is needed.

Production is the live app that real customers use. Staging is a copy set up as close to production as possible, with its own database, keys and test payment accounts, where a release is checked before it goes out. Preview deployments are short-lived copies built for each pull request, each at its own URL, so a reviewer or client can click through a change before it is merged.

Vercel, Netlify and Cloudflare Pages create previews automatically. The environments differ mainly in their environment variables, and keeping them apart matters: a staging site pointed at the production database, or test emails sent to real customers, are classic accidents. Previews of unfinished work are best kept out of search engines, and behind a password where needed.

VS Code combines a quick editor with many features of a heavier IDE: autocomplete and error checking through language servers, a debugger, Git integration, a built-in terminal and a huge extension marketplace for languages, linters, formatters and themes. It runs on Windows, macOS and Linux, and its remote extensions let it edit code on a server over SSH, inside a container or in WSL.

It is built with Electron, and its core, Code - OSS, is open source under the MIT License; Microsoft's own build adds branding and telemetry under a free product licence. It is a different product from Visual Studio, Microsoft's larger IDE for .NET and C++. AI editors such as Cursor and Windsurf are forks of VS Code, and VSCodium ships the open-source build without Microsoft's telemetry.

The terminal is the window; the shell is the program inside it that reads commands and runs them: bash on most Linux servers, zsh on macOS, PowerShell on Windows. A CLI (command-line interface) is any program built to be used this way, such as git, npm, docker or a cloud provider's own tool. Commands can be chained together and saved in scripts, which is why automation and CI are built on the command line.

Servers usually have no graphical interface at all, so managing one means connecting over SSH and working in the shell. Windows developers often add WSL to get a real Linux shell. Terminal apps such as Windows Terminal, iTerm2 and the one built into VS Code differ in comfort features, but the commands are the same.

ESLint parses code and checks it against rules: a variable that is never used, a comparison that is always false, a React hook called inside a condition, a missing await. Each rule can be an error, a warning or switched off, and many can fix the code automatically. Plugins add rules for React, TypeScript (typescript-eslint), accessibility, imports and more, and frameworks such as Next.js ship a ready-made set.

It runs in the editor as you type, in a pre-commit hook and in CI, where a failing lint blocks the merge. Configuration now lives in a single eslint.config.js file (the flat config), which replaced the older .eslintrc files. Biome and oxlint are newer linters written in Rust that run much faster and cover many of the same rules, with fewer plugins.

Prettier ignores how the code was typed: it parses it and prints it back out in its own style, wrapping lines at a set width. It handles JavaScript, TypeScript, JSX, CSS, HTML, JSON, Markdown, YAML and GraphQL, and plugins add more, such as sorting Tailwind classes. It deliberately has very few options (line width, quotes, semicolons, trailing commas), so there is little to configure or debate.

Most teams run it on save in the editor and check it in CI, which keeps code reviews focused on real changes. It does not look for bugs; that is ESLint's job, and eslint-config-prettier switches off ESLint's style rules so the two never fight. Biome includes a largely Prettier-compatible formatter that runs much faster.

Logs are timestamped lines an app writes as it works (request received, payment failed), best written as structured JSON so they can be searched. Error tracking tools such as Sentry go further: an SDK in the app catches every crash with its stack trace, the browser or device, the release and the steps that led up to it, groups identical errors into one issue and alerts the team. Uploading source maps turns minified browser code back into readable lines.

Metrics (response times, error rates, memory) and traces (one request followed across services) complete the picture; together these are often called observability, and OpenTelemetry is the open standard for collecting them. Common tools include Sentry, Datadog, New Relic, Grafana, Better Stack and Axiom, and Firebase Crashlytics is widely used for mobile crashes. Uptime monitors check a site from outside and alert when it stops answering.