Git in PhpStorm: Branches, Rebase, Stash, and Partial Commits Done Right

1. Why Git in the IDE Instead of Just the Terminal?

The terminal is powerful, but it only ever shows a one-dimensional view of the repository's state. PhpStorm, on the other hand, presents the full context: which files have changed, which lines differ from the last commit, which branch contains which commits, and exactly where a merge conflict sits. This visual overview is not a comfort feature, it prevents errors that arise in the terminal from overlooked lines or incorrect staging.

Especially on larger PHP projects like Magento 2 with hundreds of modules and files, keeping an overview of the current working state is critical. An uncommitted configuration file, a forgotten debug statement, or an incorrectly staged migration script can affect the entire deployment. The Git integration in PhpStorm shows all of these states at a glance and enables precise action, without leaving the IDE or switching between several terminal windows.

Another advantage: PhpStorm understands the semantics of PHP files. Git Blame does not just show the author and date, PhpStorm links the blame to type inference, the method signature, and the class structure. Clicking a line in the blame view lands directly in the full commit view with a diff of all affected files, and from there you can jump straight to the original code review.

2. Creating, Switching, and Managing Branches

In PhpStorm, Ctrl+Shift+` (macOS: Cmd+Shift+`) opens the branch widget in the bottom right corner, alternatively via the Git menu or a click on the status bar. From there you can create, check out, rename, merge, and delete branches. When creating a new feature branch, you type the name and PhpStorm immediately asks whether the branch should be forked from the current position or from a remote branch.

Branch comparison is a feature that is cumbersome in the terminal but works intuitively in PhpStorm: right-click a branch, then "Compare with Current" shows all commits that exist in one branch but not the other, including a full diff. Especially useful before a merge or rebase, to understand exactly what is being combined. Remote branches are managed directly in the same dialog; fetch, pull, and push are reachable through dedicated buttons.

3. Selective Staging: Committing Only the Right Changes

The commit view in PhpStorm (Ctrl+K) shows all changed files and lets you include or exclude individual files. But the real strength lies one level deeper: the checkbox next to each file is not everything, right-clicking a file in the commit dialog opens "Show Diff," and within that diff individual change blocks (hunks) can be selected one by one. That enables atomic commits even when several unrelated changes were made in the same file.

In practice this means: you're working on a feature and notice a bug in a neighboring method, which you fix immediately. Instead of mixing both changes into one commit, you select only the bug fix lines in PhpStorm for the first commit, commit them, and then commit the feature lines separately. The result is a readable, bisectable Git history that is far more valuable for code reviews and later debugging than a "fixed stuff" commit with 20 unrelated changes.

4. Partial Commits: Hunk Selection in PhpStorm

Partial commits, committing individual lines or hunks of a file, are possible in PhpStorm via the gutter of the diff view. In the commit dialog you select a file and open its diff. In the left-hand gutter, a checkbox appears for each change group. Individual lines can be selected specifically via right-click and "Include Line in Commit." PhpStorm remembers the selection until the commit is completed.

This feature is especially valuable in long-running development sessions where several conceptually different changes have accumulated in the same files over many hours. Instead of using git add -p in the terminal with patch selection, PhpStorm offers a visual hunk editor that requires no experience with the patch format. The finished staging area is shown once more in a preview before the commit, so you can see exactly what is actually being committed.

<?php
declare(strict_types=1);

namespace Mironsoft\Catalog\Model;

use Magento\Framework\Model\AbstractModel;

/**
 * Example model demonstrating a typical change scenario
 * where partial commits are useful: bug fix mixed with feature work
 */
class ProductMetadata extends AbstractModel
{
    /**
     * Bug fix: correct null check (this goes into commit #1)
     *
     * @param int $productId
     * @return string|null
     */
    public function getEnhancedSku(int $productId): ?string
    {
        $product = $this->productRepository->getById($productId);
        // Fixed: was returning '' instead of null for missing SKU
        return $product->getSku() ?: null;
    }

    /**
     * New feature: enriched metadata (this goes into commit #2)
     *
     * @param int $productId
     * @return array<string, mixed>
     */
    public function getMetadataBundle(int $productId): array
    {
        return [
            'sku'  => $this->getEnhancedSku($productId),
            'type' => $this->typeResolver->getType($productId),
        ];
    }
}

5. Stash and Shelf: Saving Work in Progress

When an urgent hotfix comes up in the middle of your work, you need a way to set aside the current, not-yet-commit-ready changes. PhpStorm offers two concepts for this: Git Stash (the standard Git mechanism) and PhpStorm's own Shelf. The difference is important: Git Stash is portable and lives in the repository, other tools can see it. The Shelf is internal to PhpStorm and survives even when stashes would be lost through rebase or branch operations.

The stash dialog is opened via Git → Stash Changes. PhpStorm lets you assign a meaningful name and later reapply stashed changes via Git → Unstash Changes, with a preview of which files are affected before the changes are actually restored. The same applies to the Shelf: VCS → Shelve Changes saves the current set of changes with a name and timestamp. Shelves can be applied partially, which stashes cannot.

In Magento projects, the Shelf is especially useful when you're working on theme changes and need to test a database migration class at the same time. Instead of creating an unfinished commit, the theme work is shelved, the migration file is tested and committed, and afterward the shelf is reapplied. The workflow stays clean, without half-finished commits ending up in the history.

6. Resolving Merge Conflicts Visually

The built-in three-way merge editor in PhpStorm is one of the most productive ways to resolve merge conflicts. When a conflict occurs, PhpStorm automatically opens a dialog with three panels: your own branch on the left, the other branch on the right, and the result in the middle. Conflict markers are highlighted with color, and each conflict block has buttons to accept the left or right version, or to combine both.

What the terminal cannot offer: PhpStorm understands PHP syntax in the result panel. It immediately flags syntax errors, checks for missing import statements, and shows type incompatibilities that arose from the merge. This lets you see right away whether the merge result contains a compiler error, even before the merge is completed. That saves an entire cycle of committing, testing, finding the error, and committing again.

<?php
declare(strict_types=1);

namespace Mironsoft\Customer\Plugin;

use Magento\Customer\Api\CustomerRepositoryInterface;
use Magento\Customer\Api\Data\CustomerInterface;

/**
 * Plugin demonstrating a typical merge conflict scenario:
 * two developers added different validation logic to the same method.
 * PhpStorm's three-way merge resolves this with syntax awareness.
 */
class CustomerValidationPlugin
{
    /**
     * Combined result after merge conflict resolution in PhpStorm:
     * Both validation rules preserved, syntax checked by IDE.
     *
     * @param CustomerRepositoryInterface $subject
     * @param CustomerInterface $customer
     * @return array<int, CustomerInterface>
     */
    public function beforeSave(
        CustomerRepositoryInterface $subject,
        CustomerInterface $customer
    ): array {
        // Branch A: email domain validation (developer 1)
        $this->emailDomainValidator->validate($customer->getEmail());
        // Branch B: VAT number check (developer 2)
        $this->vatValidator->validate($customer->getTaxvat());

        return [$customer];
    }
}

7. Interactive Rebase in PhpStorm

Interactive rebase is the most powerful tool for a clean commit history, but in the terminal with git rebase -i HEAD~5 and the Vim editor it is an error-prone affair. Since version 2022.1, PhpStorm has offered a graphical interactive rebase dialog: Git → Rebase opens an assistant in which the commits of the current branch history are displayed as cards. Commits can be reordered via drag and drop, and actions can be assigned via dropdown: pick (keep), squash (merge into the previous commit), fixup (squash without a commit message), reword (change the message), drop (remove).

The visual representation immediately makes clear which commits will be combined and what the result will be, before the rebase starts. When squashing, PhpStorm automatically opens an editor for the combined commit message, in which all original messages are available for selection. If the rebase hits a conflict, PhpStorm switches seamlessly into the merge conflict dialog. After resolution, the rebase continues with a single button press, no manual git rebase --continue is needed.

8. Using Git Log and Blame Productively

The Git Log in PhpStorm (Alt+9 for the Git window) does not just show a list of commits, it filters in real time by author, branch, date, file, and commit message. That makes it possible to find the answer within seconds to questions like: "When was this method last changed?", "Which commits did colleague X make on the main branch this week?", or "Which commit introduced this specific configuration file?"

Git Blame (Alt+Shift+A on a line in the editor) shows the author, date, and commit hash directly in the editor gutter. Clicking a blame entry opens the full commit panel with all changed files, the commit message, and a direct link to linked issues. For Magento projects this is especially valuable: you can immediately trace why a particular layout handle or plugin was introduced at a specific point in time, with the full diff and no further searching.

9. Terminal vs. IDE: When to Use Which?

The integration in PhpStorm does not replace the terminal, but it shifts the balance considerably. Complex operations such as interactive rebase, merge conflict resolution, selective staging, and branch comparisons are more productive in the IDE. Simple, quick operations like git fetch, git pull --rebase, or checking remote status are often faster in the terminal because no mouse switching is needed.

The goal is not to avoid the terminal, but to choose the right tool for the right task. The PhpStorm shortcut Alt+F12 opens the integrated terminal directly in the project context, so switching between the IDE Git UI and terminal Git commands is a single keypress away, without leaving the editor or losing your working context.

10. Summary

The Git integration in PhpStorm makes branch management, selective staging, stash workflows, merge conflict resolution, and interactive rebase more productive than the terminal alternatives, not through abstraction, but through context. The IDE understands PHP syntax and can therefore flag syntax errors immediately in a merge result, link the method signature in the blame view, and jump directly to the affected line of code in the log.

Partial commits, the targeted selection of individual lines or hunks for a commit, are the tool for a readable, bisectable Git history in teams. The Shelf complements the stash with persistence beyond rebase operations. Interactive rebase with a visual representation makes cleaning up branch history accessible without requiring Vim knowledge. All of these workflows can be carried out in PhpStorm with fewer mistakes and less cognitive load than in the terminal.

11. FAQ: Git in PhpStorm