Page 16 - Git

Monorepo or polyrepo is one of the most consequential architecture decisions for Git projects, because it shapes commit behavior, access rights, CI/CD pipelines, and daily developer routine for years to come. This article compares both strategies against concrete criteria such as team size, coupling, and tooling, and shows how Magento agencies can sensibly split client projects and custom modules between app/code and their own Composer packages.

The atomic symlink switch is the technical core of zero downtime deployments for Magento. Instead of overwriting files directly, which creates inconsistency, the new release is fully prepared and then activated as current in a single kernel system call. Rollback is therefore not an emergency plan but a millisecond operation.

Deploying Magento stores through FTP uploads or manual file copying from a developer's own machine destroys any traceability of what code is actually live. This article shows how annotated Git tags serve as an immutable production truth, how CI/CD pipelines automatically react to branch and tag pushes, how a clear branch-to-environment mapping cleanly separates staging, review environments, and production, and why a rollback under pressure is nothing more than redeploying the previous tag.

A commit without a ref is practically invisible to Git. Branches, tags and HEAD are all just named pointers that turn a loose pile of objects into a navigable history. This article shows how .git/refs/heads, .git/refs/tags and packed-refs are laid out on disk, how HEAD resolves to a commit in two hops, and how to inspect and manipulate refs directly with git show-ref, git symbolic-ref and git update-ref.

Code reviews without context cost time and produce surface level nitpicking. PhpStorm provides the tools to prepare reviews in a structured way through Git diffs, File History, the Annotate view and the TODO tracker, without ever leaving the editor and without relying on the GitHub UI as the only source of context.

After a deployment, the full page cache is empty. The first real visitors experience load times that have nothing to do with actual shop performance. An automated warmup job in GitLab CI fills the cache with the most important pages before the first human ever opens the homepage.

Teams that never tag their deployments and never maintain version numbers lose track of what ran on which server and when. Release tags make every Magento deployment unique, traceable and instantly rollback capable in an emergency.

A GitLab pipeline made up of a single long script block is not a CI/CD process, it is automated chaos. Only once Build, Test, Package, Deploy, Verify and Rollback are modeled as distinct stages does a pipeline become traceable, rollback capable and workable for a whole team.

A rollback that only gets written once things break is not a rollback at all. If the rollback script is not finished before the first deployment, it will be tested for the first time under pressure and stress, exactly when everything needs to happen fast.

A deployment to staging can happen automatically, a deployment to production needs a deliberate approval. GitLab Environments, when: manual and deployment approvals implement exactly this approval model, complete with a visible deployment history and variable scoping based environment isolation.