I’m new to git.
I’m using a development platform called automation studio.
This development tool creates all sorts of files and directories which it needs to maintain runtime and IO information for the target processor. These informations are specific for each project.
Therefore these file should not be under version control because they are provided and maintainded by the platform. Otherwise one cannot run the automation studio without these files.
I put the names of these files and directories in an .gitignore file.
Then I cloned myrepository to a bare repository on a server.
Then I cloned back to mynewrepository on my local machine.
Unfortunatedly in mynewrepository all files and directories listed in .gitignore were missing. Therefore the automation studio platform failed to work.
How can I exclude these files and the content of these directories from versioning but keep the them all in the repository in order to clone back a fully working project for automation studio?
2
Sometimes there comes situations where you want to add configuration to version control but they change depending on where you’ve cloned the project. How to “semi-ignore” these files depends totally on how you want it to work. So here are some strategies for it:
Strategy No. 1: Commit ALL THE THINGS
You should try to commit everything and see later on what you don’t need. Sometimes this is the best solution. It is more common for us to assume that we don’t need them in version control until we realize that we do.
You can also follow it up with temporarily assuming files as unchanged in git. The command you can use to do this with is git update-index:
git update-index --assume-unchanged [file ...]
If you have trouble doing this with directories, read this SO question on assuming directories with untracked files.
Strategy No. 2: If a tool sets up the project, use it to generate the configuration and then clone on top of that
You can do what you’ve done now, ignore the configuration in git and when you want to clone the project you do that on top of a new project that is created by the tool. Or write your own tool (a batch script) to set up the project for you.
Strategy No. 3: Check in “default” configuration shared between projects
You could try to figure out which configuration is the bare minimum that you need and have that committed to the repository.
If you want configuration defaults, you could copy (or zip) all the configuration files to a seperate directory and then have that committed. When you clone, you can then unzip all those files to the correct spot to get things going.
You can batch this installation process to make it easier for you to get going. So that you only need to run it once when you clone the project.
Bonus Strategy: Check in a “readme” text file that details a process of how to get started
Checking in a text file that details how you go about to set up the project is a useful thing to do. You may need this later on to remind yourself how you’ve set up the project.
2
This cannot possibly work. Git cannot clone any files that it doesn’t even know exist. That doesn’t even have anything to do with Git, that’s just basic common sense.