A clean Git merge is not a PCB review
Use source history, visual inspection and engineering checks together. Keep the review decision attached to the exact combined design that will continue into development.
Published
A merge can finish without a text conflict while the combined design still needs engineering review. These are different questions: could the files be combined, and does the resulting board implement the intended design?
That distinction is a reason to use Git with a review process. KiCad 10 includes Git integration in its project manager. External tools can also add visual output to Git-based review. See the KiCad manual and kicadiff documentation.
Start with intent
Consider a hypothetical request to move a connector to fit an enclosure while preserving its interface. A reviewer needs to evaluate more than whether the connector appears at the requested position. The scope could include orientation, mapping, connected routing and mechanical context. Applicable checks depend on the actual board and requirements.
Identify the baseline, candidate, intended change and important constraints that should remain true. This gives the reviewer a concrete question to answer.
Use three kinds of evidence
Source history records the files and their changes. Keep the exact candidate identity so another engineer can retrieve what was reviewed.
Visual inspection helps a person examine spatial relationships and design changes. Confirm the comparison uses the intended versions and its required data is available. A missing or incomplete view is not evidence that nothing changed.
Checks and engineering judgment address different parts of correctness. Record which checks ran, against which source, and what was outside their scope. A displayed difference is not an electrical pass verdict; a passing rule check does not answer every question about intended behavior.
These records answer different questions. Keep their limits visible in the review.
Review the combined result
If changes were merged, review the combined result that will continue into development. Earlier screenshots from each contributor may describe different inputs. Confirm the resulting source opens in the relevant tool, inspect the intended change and nearby context, and resolve open questions.
Keep the decision attached to the candidate identity. When another edit produces a new candidate, make that visible to the reviewer. An approval for an earlier version does not automatically cover whatever a moving project link opens today.
Make the handoff easy to repeat
A short review packet can contain exact versions, change intent, required context, check references, unresolved findings and the reviewer decision. It can live in your existing repository or issue tracker. The hardware-to-firmware handoff guide includes downloadable blank templates.
BoardRepo supports inspection of saved designs within their access boundaries. Comparison requires signed-in access to both versions and compatible, available comparison data. It does not merge CAD designs or provide simultaneous editing. Use the KiCad version-control guide and revision-comparison guide to evaluate the documented workflow.
This is a suggested review method with an illustrative scenario, not a customer case study or a measured demonstration. A useful next step is to try it on an owned design and record the actual obstacles and findings.
More in News.