Page 15 - Git

Waving commit messages through without validation builds up months of history full of entries like fix and wip that are useless for changelogs and automated releases alike. The commit-msg hook checks every message before the commit is created, and commitlint together with Husky enforces a consistent format that tools like semantic-release can reliably parse.

Local Git hooks live in .git/hooks and are never versioned with the repository, so every developer has to set them up individually and teams end up with no reliable way to enforce code quality before a commit. Husky distributes hooks automatically through npm, lint-staged limits checks to changed files, and commitlint enforces clean commit messages, all without manual setup.

Client-side Git hooks are convenient, but every developer can bypass them with --no-verify, delete them, or simply never install them. Server-side hooks, by contrast, run on the central Git server, where nobody has direct access, making them the only real enforcement point for force-push protection, file size limits and branch naming conventions across the team.

Git submodules promise to cleanly stitch multiple repositories together, but in practice forgotten updates, a confusing detached HEAD state, and diverging commit pins across the team cause frustration on a regular basis. This article explains how submodules technically work, compares them with git subtree, Composer based dependencies, and monorepos, and shows which tool actually fits typical Magento multi repo setups.

Rewriting the same Bash functions for logging, retry logic and notifications in every repository creates maintenance overhead a single, shared library file avoids. Built, versioned and tested properly, such a Bash library becomes the stable foundation for every CI pipeline on a team, instead of the next source of copy-paste bugs.

Every Magento deployment handles sensitive data: SSH keys, database passwords, Composer auth tokens, Redis connections, and API keys. The question of where these secrets are stored determines how exposed a deployment process is in the event of an incident. GitLab CI/CD variables are a practical starting point, but they are not the best choice for every secret.

A self-hosted GitLab Runner gives teams full control over the build environment, security, and access paths. This article explains installation on Linux, registration with the Docker executor, tags, security settings, and Magento-specific configuration, step by step and in full.

Merging an entire feature branch just to ship one hotfix drags unwanted commits, conflicts, and noise into your history. Git cherry-pick applies exactly one commit onto another branch, with its own SHA and traceable origin through the -x flag. This article shows how to use cherry-pick deliberately for hotfixes, resolve conflicts, and avoid divergent history.

If you only find out about quality gates in the CI pipeline, you lose minutes or hours on feedback loops that could have been resolved locally in seconds. PHPStan, PHPUnit, PHPCS and Rector can be integrated into PhpStorm so that errors become visible right at the moment you save, without ever leaving the command line.

Anyone who stores Composer credentials in the repository risks compromise at every offboarding. Anyone who does not manage them at all ends up fighting broken builds. This article shows how to store auth.json, private repository tokens and Packagist mirror configurations securely as GitLab variables and consume them correctly in pipelines.