Git and CANoe Configuration Management

Version the experiment's inputs deliberately

A useful CANoe repository should let a colleague recover the intended configuration and understand what changed. “Commit every file” is too broad: generated binaries, private workstation settings and new recordings serve different purposes from source and controlled replay inputs.

This is a conservative collaboration policy for a project the team can rebuild. It is not a claim that Git or Vector requires this exact layout. First classify the dependencies using the file-role walkthrough.

Make the tracked set explicit

Usually track the main configuration, CAPL source and includes, required databases, panels and test sources. Record how to obtain necessary external DLLs and options. For each generated or third-party file, decide whether it is reproducible, redistributable and needed for a clean checkout. A project supplied only as binaries needs a different policy from a source-based teaching project.

For a project that can regenerate its CAPL binaries and keeps new recordings in one dedicated directory, a starting .gitignore could be:

# Generated only when the project can rebuild them from tracked sources
*.[cC][bB][fF]
# Dedicated directory for newly captured output, not replay fixtures
/RunEvidence/

Do not copy the rules blindly: required binary-only dependencies must remain available, and controlled replay fixtures belong outside the ignored output directory. Ignore rules do not untrack files already committed. Check the intended pattern with git check-ignore -v <path>, and inspect the staged diff before committing. See the official gitignore documentation.

A readable configuration is not necessarily safe to merge

Even if your CFG is readable text, a line merge can produce an internally inconsistent configuration. For a small team, nominate one editor for configuration changes while other contributors work on separate CAPL sources. This is coordination, not a lock automatically enforced by Git.

If the team deliberately wants configuration conflicts resolved by selecting and validating a whole version, this optional .gitattributes rule disables Git's textual merge for CFG files:

*.[cC][fF][gG] -merge

This rule does not turn a text file into a binary file, establish an exclusive checkout or choose the correct configuration. Concurrent changes still need resolution, followed by opening and validating the selected result in CANoe. Attribute behavior is documented in Git's merge attribute reference.

Avoid adding a repository-wide line-ending conversion rule until you know the files' encoding and the tools that write them. A mass normalization diff can obscure a real configuration change.

Review the change as a working experiment

For a CAPL edit, inspect the event path, input preconditions, state reset and expected output. For a CFG edit, describe which node, channel, database, panel or dependency changed. A comment such as “update project” is insufficient when a channel mapping changes the meaning of the same source.

Consider this failure: two contributors separately add a node and change a database path. A successful textual merge can retain both lines while referring to a database absent from the checkout. The merge result needs dependency validation, not just conflict-marker removal.

Use a clean-checkout acceptance procedure

Only record an actual pass after executing these checks. The procedure is a proposed policy, not a test report for a downloadable project. Keep result files associated with their run and source revision so that a later source change does not inherit an old passing claim.