How much of project environment should be under version control

[BTrem.1]

Build environments are pretty touchy with project tools that generate middleware code and changing tool versions. Given this environment , (1) what files should be under version control? (2) If the project has 30 user modified source files and 150 tool generated files, should all 180 files be under source control?

Given the state of build tools I'm not entirely convinced that 6mo from now the 150 tool generated files could be duplicated if lost. (3) besides separately controlling user files should I check-in a zipped project folder?

I'm looking for insight on what others are doing. In the past I generally put under source control only my user generated files.

[Pavel A.]

> If the project has 30 user modified source files and 150 tool generated files

Do these "generated files" include the HAL library .c and .h files? "BSP" files? If so, probably you need a different approach.

Instead of copying this stuff into your project, use option to reference shared lib files.

Note the current HAL library version (or keep it in a separate repo with your own versioning).

> (3) besides separately controlling user files should I check-in a zipped project folder?

If this adds you more comfort, why not. But git is not great to keep large binaries. Use LFS or something else such as github releases or Artifactory.

-- pa