Page 14 - Git

The symlink switch is only the beginning. Search index reindex, queue consumer restart and cache warmup are the three hidden waiting periods after every Magento deployment, and they need to be coordinated within the pipeline.

A single web server is rarely the reality in Magento production systems. When web servers, worker processes, cron jobs and queue consumers are spread across separate hosts, the GitLab pipeline has to coordinate that complexity, without race conditions, orphaned processes or partial deployments.

env.php does not belong in the repository, and it does not belong in the build artifact. Ignore that rule and you end up with a release model that breaks at the first environment switch. This article explains how app/etc, shared directories, and config.php correctly work together in the symlink release model with GitLab CI/CD.

In Magento projects with several developers working in parallel and regular module updates, a merge conflict in composer.lock is one of the most common Git problems, and also one of the most commonly resolved incorrectly. The file is machine generated, several thousand lines long, and contains a hash that must match the actual composer.json, which is why manually merging the conflict markers almost always produces a file that is inconsistent but looks superficially valid. This article walks through the correct resolution path and how such conflicts can be reduced across a team in the first place.

Forgetting to update Composer after every pull costs time chasing cryptic error messages. The post-merge hook handles routine tasks like that automatically, without anyone having to remember.

Three roads, one destination: getting Magento onto the server safely. Shell scripts are simple but hard to maintain. Deployer PHP understands release structures and rollback out of the box. Ansible is powerful, but overkill for many teams. Which approach fits when, and what does that look like in a GitLab pipeline?

Anyone working with GitLab CI/CD in a larger team knows the phenomenon: jobs sit in the queue even though the pipeline was triggered long ago. The cause is almost always concurrent limits set too low, missing runner tags, or unbalanced load distribution between build, test and deploy jobs.

A cumbersome pull request workflow slows entire teams down, huge diffs, missing context, and manual merge coordination all add up to friction. This article shows how small pull requests, draft PRs, PR templates, and required checks with auto-merge work together to make reviews faster and the whole workflow more predictable.

Anyone pushing over HTTPS knows the constant password prompt. Credential helpers solve that, but they differ significantly in security, persistence, and platform support.

Squash merge promises a spotless main history with one commit per pull request, but that convenience comes at a cost. Collapsing granular commits too eagerly sacrifices bisect precision, authorship, and the documented path behind large refactors. This article explains how squashing works mechanically, when it genuinely helps teams, and when rebase merge or merge commits remain the better choice.