====== 5.7 Git Environment ====== [[fxdemo:05-part:start | Go To Top ]] [[fxdemo:05-part:05-development-environment:start | Return to Development Environment ]] The development environment must include [[dido:99_annexes:annex-b-terms-and-definitions:g:git|Git]] because the Phase 0 [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] depends on a controlled [[dido:99_annexes:annex-b-terms-and-definitions:r:repository|Repository]] structure, change review, decisions on generated [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifacts]], Baseline tagging, and reproducible collaboration. Developers should configure Git before making Phase 0 changes. At a minimum, each developer should have a configured user name, email address, line-ending behaviour, and access to the shared Repository. The team should document any required branch-naming, commit-message, pull-request, review, or tagging conventions in the Git and Review Workflow section. The Git environment should support clean review. Developers should avoid committing local build outputs, virtual environments, runtime logs, temporary files, editor caches, or machine-specific [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]]. The ''.gitignore'' file should protect the Repository from common accidental commits. The team should use Git tags, branches, or release markers to identify important Phase 0 Baselines. When the team changes Repository layout, generated Artifact policy, [[dido:99_annexes:annex-b-terms-and-definitions:t:type|Type]] definitions, scripts, [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]] patterns, containers, or acceptance criteria, the Git history should show that change clearly. ---- © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.