Using Sourcetree’s Line‑Level Staging for Cleaner Commits

The problem: messy edits in a single file

You finish a coding session and find that one file now holds three unrelated changes: a bug fix, a leftover debug print, and an import reorder. Committing them together creates a "misc fixes" commit that obscures intent, slows down code review, and makes git bisect less useful.

Thesis: commit granularity is an engineering decision

Small, single‑purpose commits speed up review, keep reverts safe, and give git bisect meaningful checkpoints. The barrier to achieving this granularity is often the perceived extra effort. Sourcetree’s line‑ and hunk‑level staging lowers that effort by letting you stage exactly the lines you want, directly from the diff view.

How line‑level staging works in Sourcetree

1. In the Unstaged files pane, click a file to see its working‑copy diff.
2. Highlight the specific lines that belong to one logical change (you can select across multiple hunks).
3. Right‑click the selection and choose Stage Selected Lines (the destructive counterpart is Discard Selected Lines).
4. Sourcetree updates Git’s index immediately; the staged pane now shows only those lines, while the rest of your edits remain in the working copy.

This operation is the GUI equivalent of running git add -p (patch mode) or git checkout -p for discarding.

Worked example: splitting a bug fix, debug print, and import reorder

Assume a local repository at <repo-path> with a file src/utils.py that currently contains:

# src/utils.py
import os
import sys

def calculate(value):
    # DEBUG: print intermediate value
    print(value)
    return value * 2

You have made three edits:

• Bug fix: changed return value * 2 to return value + 2.
• Debug print: added the line print(value).
• Import reorder: swapped import os and import sys.

To create two clean commits:

1. Open Sourcetree, ensure src/utils.py appears under Unstaged files, and click it to view the diff.
2. Highlight only the lines that constitute the bug fix (the changed return statement). Right‑click → Stage Selected Lines.
3. Verify the staging: open a terminal, run git diff --cached. You should see only the return‑line change.
4. Commit the staged lines with a message like "Fix: return value + 2 instead of * 2".
5. Now highlight the debug‑print line, right‑click → Discard Selected Lines (or stage it for a separate commit if you prefer to keep it).
6. Finally, stage the import reorder lines and commit them with a message such as "Chore: reorder imports".

Result: two focused commits from one editing session, each with a clear purpose.

Trade‑offs and limitations

• Speed vs. foresight: Splitting after the fact is slower than making small edits as you go. If you anticipate needing separate commits, stage early.
• Interdependent changes: If the bug fix relies on the import reorder, staging them separately may produce an intermediate commit that fails to build or pass tests. Test each staged state before committing.
• Irreversible discard: Discard Selected Lines permanently removes the highlighted uncommitted work; it cannot be recovered via git reflog. Use it only when you are certain the lines are unwanted.
• Text‑only: Binary files cannot be split; they stage as whole files.
• Rebase/merge constraints: During an active rebase or merge‑conflict resolution, line‑level staging may be disabled; conflicted hunks must be resolved at file level.

Actionable closing: verify and adopt

To confirm that Sourcetree’s line‑level staging matches the CLI:

1. Create a scratch repository and make two unrelated edits in the same file.
2. In Sourcetree, stage one edit’s lines via Stage Selected Lines.
3. Run git diff --cached in a terminal; it should show only the selected lines.
4. Run git diff; the remaining edit should still appear.
5. Repeat the split in a second clone using git add -p and compare the git diff --cached output—both methods should produce identical index states.

If the outputs match, you can trust the visual selection to produce the same granularity as the command line. Incorporate line‑level staging into your workflow to keep commits purposeful without sacrificing the convenience of a GUI.