A compressed file bearing the project name arrives, and you open it to find many folders. Is this the version you requested? Does it contain the materials a maintenance team will need? A code handover needs a description of content and references: file size, filename and folder count cannot answer those questions.
Define the delivery materials first
Ask the development company to name what it will deliver: a source snapshot for a specific version, a repository copy containing the agreed history, or additional documentation and supporting materials. You may need several items, but each should have an identified location and an explanation of exclusions.
Consider a fictional exhibition-preparation platform whose owner requested the source corresponding to a reviewed version. The archive opens, but some large files are text pointers and revision history is absent. This illustrates a handover question; it describes neither a customer project nor an actual repository download.
A source snapshot and repository history are different materials
GitHub documents its generated source archives as snapshots of a branch, tag or commit, without complete repository history. Ask which delivery format is required instead of accepting “the code is on GitHub.” This concerns GitHub-generated archives, rather than every ZIP a provider might assemble manually.
If history forms part of the agreement, define its extent, delivery format and reviewer. Some explanations of development decisions may live in separate documentation. Technical history alone will not necessarily explain every decision or restore discussions that were never retained.
A package inventory card
Complete this card with the provider and technical reviewer. Its purpose is to connect each material to a location and evidence, rather than collect an unmanageable file list. Record when a project does not use large-file storage or another component instead of adding irrelevant requirements.
| Material | Question | Receipt evidence |
|---|---|---|
| Source snapshot | Which version and scope? | A version reference and comparable content |
| Repository history | Is it included, and in what format? | A distinct item with defined boundaries |
| Large files | Actual files or pointers? | Availability of the required materials |
| Documentation and separate materials | Where are they, and which version? | Receipt evidence or an owned exception |
Add a status to every row: received and reviewed, received but unreviewed, or missing. An unopened file is not missing, but its delivery is not fully verified either. Separating these states reveals what awaits review and what requires redelivery, instead of hiding both behind one acceptance tick.
What sits behind a file pointer?
GitHub's LFS documentation says archives contain pointers by default, with conditional options to include tracked objects; externally hosted LFS files are not included through the same mechanism. Establish the project's actual configuration without assuming it uses LFS or that one setting retrieves every external asset.
In the exhibition example, the reviewer records that a required maintenance material has not arrived in the agreed form and assigns its completion. A plausible filename is insufficient. Equally, the archive should not become a request for materials that cannot be handed over or production secrets; rights and access belong in their appropriate agreement.
Connect the package to the reviewed version
Record the version reference rather than relying solely on a moving branch name. GitHub distinguishes commit-content stability under documented conditions from movable branches and tags. Compression bytes can also change without changes to extracted files, so a different archive hash alone does not explain a source difference.
Agree on the specialist's comparison method and retain its result. A content match does not automatically establish successful building, operation or application security: those are separate checks. If the reference changes after review, retain the reason and required rechecks instead of silently replacing the delivered material.
Consult code and data rights questions for the wider agreement and build and deployment evidence for separate operational verification. When discussing custom software with Nextwave, attach the package card, version and exceptions to make delivery reviewable.
Sources and limits
GitHub's source-archive and archive LFS documents were read on 4 November 2026. No download, transfer or build was performed. Prepared with AI assistance and information and translation review.
