====== 4.9 Git-Controlled and Non-Git-Controlled Content ====== [[fxdemo:05-part:start | Go To Top ]] [[fxdemo:05-part:04-repository-layout:start | Return to Repository Layout ]] The [[dido:99_annexes:annex-b-terms-and-definitions:r:repository|Repository]] should clearly distinguish between [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifacts]] that [[dido:99_annexes:annex-b-terms-and-definitions:g:git|Git]] tracks and those it ignores. This distinction protects [[dido:99_annexes:annex-b-terms-and-definitions:r:reproducibility|Reproducibility]] and prevents local machine outputs from polluting the shared [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]]. Git should normally track: - Handwritten source files. - [[dido:99_annexes:annex-b-terms-and-definitions:i:idl|IDL]] source definitions. - [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]] templates and Baseline Configuration files. - Build and run scripts. - Container definitions. - Tests. - Documentation. - Controlled-generated Artifacts, if the team explicitly decides to [[dido:99_annexes:annex-b-terms-and-definitions:v:version|Version]] them. Git should normally ignore: - Local virtual environments. - Machine-specific environment files. - Build outputs. - Temporary generated files. - Runtime logs. - Container runtime Artifacts. - Local IDE cache files. - Developer-specific override files. The ''.gitignore'' file should document these decisions through clear patterns and comments. If the team decides to Version a generated Artifact, the Repository should explain why that Artifact belongs in Git and how developers should regenerate or verify it. The Repository layout should make Git review easier. Reviewers should be able to identify whether a change affects architecture-facing definitions, handwritten implementation code, generated outputs, Configuration, scripts, tests, documentation, containers, or runtime Evidence. ---- © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.