Multi Source Inventory (MSI) is one of the largest refactorings in Magento 2 history – introduced in version 2.3. Instead of a single global stock state, products can have stock in multiple sources (warehouses, physical stores, dropshipping). The Source Selection Algorithm decides which source to fulfil the order from. I show the MSI architecture, how the default algorithm works, and how to write a custom one.
Flyweight is a structural pattern that minimises memory usage by sharing as much data as possible between similar objects. Instead of creating thousands of objects with repeated data – you create one object and references to it. In Magento 2 this pattern appears in many places: translations, store configuration, EAV objects. I show an implementation from scratch and how to recognise it in existing code.
Skip List is a probabilistic data structure invented by William Pugh in 1990. It combines the simplicity of a singly linked list with the performance of a binary tree – search, insert and delete operations run in O(log n) on average, without the need for balancing like AVL or Red-Black Trees. Rarely used in PHP, but it illustrates perfectly how randomness can replace complex balancing algorithms.
Every developer eventually breaks something in a repository. Good news: Git rarely loses data permanently – reflog records every HEAD change. Bisect cuts hours of regression hunting to minutes. Reset has three modes and mixing them up causes pain. Revert is the safe alternative on public branches. This post is the rescue map.
Git hooks are scripts that run automatically on Git operations. A pre-commit hook run before every commit eliminates a class of errors before they enter history. Commit-msg enforces message conventions. Pre-push protects the remote branch from broken code. I show how to configure this in a Magento 2 project with DDEV.
The choice of Git workflow has a bigger impact on team productivity than most technical decisions. Git Flow, GitHub Flow, trunk-based development are complete models for work, code review, and deployment. I show when to use each and what separates a good pull request from a bad one.
Working with remotes is everyday work in every team – but many people only use git pull and have a vague idea of what actually happens. Tracking refs, the difference between fetch and pull, when to use --force-with-lease instead of --force, and how remote branches actually work is knowledge that saves you from irreversible mistakes.
The question “merge or rebase?” is one of the most common in Git-using teams. Both strategies achieve the same result – integrating changes – but produce completely different history. There is no single right answer, there is context. I show when to use each, how conflicts work, and why fast-forward is not the same as “no merge commit”.
Commit history is project documentation – other developers read it, git bisect searches it for bugs, and git blame explains decisions. Good commit messages, the ability to tidy history before a merge, and knowing cherry-pick and bisect are tools that separate someone who “uses Git” from someone who “manages” it.
Most developers use Git like a magic box: you type something, something gets saved, history somehow works. Until something goes wrong. To stop Git being a black box – start by understanding what actually lives inside the .git/ directory. Four object types: blob, tree, commit, tag. That is it. Everything else follows from these.