Page 7 - Git

Which variables need to be set? How should jobs be structured? In what order do Magento commands need to run? This cheatsheet answers these questions compactly and completely, as a reference for everyday deployment work.

setup:di:compile is one of the most time consuming steps in the Magento build process, and one of the most frequently misplaced. Run it too early and the full Composer base is missing; run it too late and it delays the deploy. This article shows when and how di:compile should run in a GitLab pipeline.

A review that briefly bumps your own feature branch out of the way costs more than just the time spent on git stash and git checkout: running dev servers, compiler watchers or Docker containers often fall out of step too. git worktree instead sets up an additional, independent checkout of the same repository in its own directory, keeping the branch under review open alongside your own work in progress. This article shows how to use worktrees deliberately for reviews, manage them, and clean them up again.

GitLab Review Apps promise a preview environment for every feature branch. That sounds tempting, but Magento is not a simple Node.js project. A database, media storage, Redis, Elasticsearch and a complex build process turn Review Apps into a serious infrastructure project.

The three checkboxes when creating a GitLab variable look harmless, but the combination you choose for each variable determines the security of the entire deployment process. Protected, Masked and Environment Scope mean three different things that get confused constantly.

Every CI pipeline typically starts with a checkout, and for repositories carrying years of history, that single step alone can eat noticeable time. Shallow clones cap the transferred history at a configurable depth and often reduce checkout time and network volume drastically, but they also bring real limitations that can turn into a problem depending on the pipeline job. This article explains how shallow clones work, where they pay off, and where they hurt more than help in Magento deployment pipelines.

A symlink rollback is not always enough. When database migrations are part of the deployment, a current DB backup must exist before the first migration step runs, not after.

Anyone who reflexively runs cache:flush after every deployment clears more than necessary and drives up load through needless cache regeneration. Precise cache invalidation after a release is a technical decision, not a habit.

PHPStorm is far more than an editor with syntax highlighting. Anyone who only uses the surface gives away dozens of minutes every day. The right combination of shortcuts, plugins and team configuration makes the difference between an IDE that gets in the way and one that actively supports the developer.

A build job on production is not a deployment, it is an uncontrolled experiment on the live system. Artifacts from isolated CI jobs bring reproducibility, speed and safety at the same time.