Disclosure: This draft was generated with AI and checked against the cited primary sources, with a separate AI editorial review. It was prepared for the FrameSprite team, which has a commercial interest in FrameSprite. Proposed examples are not executed tests unless explicitly identified as recorded fixture results.
Lock the editable file that another artist must not overwrite, and separately reserve any related exports or metadata that must move with it. A file lock is narrower than a whole character workflow. The team still needs a handover rule for generated outputs, sidecars, and unfinished changes.
Key Takeaways
- Define the logical asset set before choosing lock paths.
- Verify server and client locking behavior in your environment.
- Release the lock after a recoverable handover, not just after closing the editor.
What a file lock actually covers
The Git LFS lock manual describes a server-side lock for a specified path. It is intended to prevent conflicting updates. Do not assume that locking hero.aseprite automatically reserves hero.png, its timing file, or every export in a neighboring folder.
Write down which file is the source of truth and which files are generated. If two artists can safely edit different masters, a whole-folder reservation may block useful work. If both masters export to the same atlas, independent source edits can still collide at the delivery stage.
Choose a lock and reservation policy
For a small project, use three responsibilities: the artist owns the editable-master lock; the export owner controls the shared output destination; the reviewer approves the delivered revision. One person may fill all three roles, but the responsibilities remain distinct.
Before editing, check existing locks and announce the intended asset scope. Confirm that the branch contains the latest approved master. Avoid treating successful lock acquisition as proof that the working file is current.
Use .gitattributes to inspect how the repository handles the relevant file types. Tracking a file with LFS, marking it lockable, and enforcing a team reservation are related decisions with different effects. Verify the actual hosting and client configuration instead of assuming a universal enforcement policy.
Example: a master and a shared atlas
An artist repaints knight/body.aseprite while another adjusts knight/weapons.aseprite. Separate locks let both work. However, both exports update knight/full-character.png and a shared attachment table.
Reserve the atlas assembly step for one owner. Integrate the two approved masters into a candidate export, then check weapon contact across the affected poses. A lock on either source file would not itself detect a mismatched attachment table.
If an export is rejected, keep the master revision and notes available so the next artist can continue. A reservation should say whether another person may rebuild the candidate while the source lock remains held.
Unlock with a clear handover
The unlock manual documents how locks are released. Force-unlocking someone else's work is an administrative exception, not a shortcut around communication. Confirm that their changes are recoverable and that the active editor will not later overwrite the newly accepted file.
Finish by recording the source commit, output location, review status, and remaining work. Verify that another collaborator can obtain the intended master and identify its exports. Then release the relevant lock and reservation.
These steps are a proposed collaboration contract, not a claim that locking eliminates all merge conflicts or lost work. The example has not been run against a particular LFS server.
Continue the workflow
Use the Why is a teammate’s sprite PNG only a few lines of text? for the neighboring problem. Keep the animation handoff checklist with the delivered package, and preserve its visual decisions in the game-art reference board.
Sources and editorial responsibility
Prepared by the FrameSprite Workflow Team. See the editorial method or contact the team with a reproducible correction. Sources checked 2026-10-20.
Top comments (0)