Keeping Unpublished Work Safe During a Portfolio Update

Separate the release from the drafts

The photo update was prepared in a separate clean checkout. That kept its release small without forcing unfinished work into a commit.

This approach has a cost: the original checkout must eventually catch up with the published branch. A clean release checkout does not automatically update every other copy of a repository. Treating them as interchangeable would hide the next maintenance task.

Before changing a working copy, I want answers to three questions:

• Which tracked files have local changes?
• Which files are untracked and therefore absent from the current commit?
• Which changes belong to the release being prepared?

A useful starting inspection is:

git status --short
git diff --stat
git diff --cached --stat

These commands answer different questions. An unstaged diff is not the same as the staged content of the next commit, and neither is a complete backup of untracked files. The Git diff documentation explains those comparisons.

Preserve the changes that are outside the release

On November 5, the original checkout was brought up to the already-published photo commit. Before that synchronization, its unfinished files were backed up. The local sitemap changes were temporarily set aside because the incoming update also touched that file.

This was a scoped operation, not a cleanup of the whole repository. Git supports restricting a stash to selected paths. Its stash documentation also distinguishes applying a saved change from removing the saved entry.

That distinction matters during verification. A retained recovery copy is useful until the restored work has been checked. It is not a task waiting to be applied a second time.

Untracked files require their own attention. Seeing no unexpected tracked-file differences does not prove that an unpublished new file has been preserved.

Verify the content, not just a successful command

The synchronization was a fast-forward to the existing published commit; it did not create a new release commit or push. The verification record checked that four unrelated files remained byte-for-byte intact and that the unpublished sitemap changes were preserved after being reapplied.

A fast-forward-only update can reject divergent history, as described in the Git pull documentation. That does not make it a substitute for reviewing local work. If the histories diverge or the restored changes conflict, the next step is inspection, not a destructive reset.

For a shared file such as a sitemap, the correct final result may differ from both earlier versions: it should contain the incoming published change and the legitimate unfinished local changes. Checking only that the file exists would miss that distinction.

Keep repository state separate from public delivery

The Photo Stories page and its original image were checked after publication. That was a separate verification from checking Git.

A commit identifies repository content. A successful HTTP response establishes that an address responds. Neither fact, by itself, proves that the intended image is delivered or framed correctly on a phone. For the gallery update, delivery checks included the image bytes, dimensions, page context, and desktop/mobile presentation.

A narrow completion checklist

For a small release with unfinished work nearby, my checklist is:

1. Record the starting repository state.
2. Separate release files from unrelated drafts.
3. Preserve both tracked and untracked work.
4. Inspect the intended update before integrating it.
5. Compare the preserved work after integration.
6. Verify the deployed page independently.

The useful outcome is not an empty working tree. It is a clear account of what changed, what stayed unpublished, and what readers can actually see.

More verified project work is available in my portfolio, or return to the technical writing index.