How to set up a git repository for an IDE-based project?

Question

I work mostly with embedded applications (FPGAs and microcontrollers) and I'm fairly new to git and version control in general. I've come to learn the power of it and want to set up some of my projects for co-workers and friends to collaborate with me. These projects are typically developed in an integrated development environment (IDE) such as MPLAB-X, Code Composer Studio, Libero, or Quartus, which generate binaries, provide background bugging, and other features. I've had some trouble setting up the project in a repository where someone else can clone it and get to working on it. I've found that most recommended .gitignore settings have you ignore the main project file as well as all of the extra binary file and bi-products such as .tcl scripts and text reports. By ignoring these, I find that I am removing all of the information that a collaborator would need to set up the development environment with the same configurations. However, if I track them in the repository, then my repository gets bogged down with extra files (often large ones) that aren't important. Is there a better solution to this problem?

Answer 1

My rules are:

• there needs to be a single command that sets up the environment after a checkout
• files under version control may not change during execution of the setup command or a build.

The weaker rules are:

• there should be no redundant information in version-controlled files
• making changes leads to a minimal difference

I have per-file-type filters configured that normalize the files before check-in. For QuartusII, these are:

• .qpf and .qsf have the datestamp removed. These load just fine, and Quartus just writes a new one, which is then removed again on the next checkin.
• .qsf is run through a normalization step (Quartus has an explicit "save normalized project file" command).
• .vhd files containing IP megafunctions are reduced to the recovery information comments, and regenerated by the setup script.
• .qip files are ignored (these are regenerated along with the megafunction)

Granted, there is an initial overhead, and this is difficult to set up, but this allows me to review individual commits as diffs easily.

Introducing these filters later on is possible by git filter-branch, so I wouldn't let that impede development and just check in everything until filters are in place.

Answer 2

The general solution is to:

• include anything able to rebuild those extra large (often binary) files
• include a reference to an artifact repository (like Nexus) or any other referential you want able to store multiple versions of those large files

Tracking rebuild scripts or references are the two ways to keep your repo a source management tool.