Question :
I have a certain folder and logs which is essential for the operation of my application. I would like to add the same in my repository, to whom replicate does not want to be creating the same when doing git clone . But the detail is that the log files should not go to the repository, but just the folder.
How to do this?
Answer :
To do this in git simply add a .gitignore file within the desired folder and then determine that all files except .gitignore will be ignored within that folder.
Structure:
logs/
.gitignore
Content of .gitignore that is inside the logs folder:
*
!.gitignore
Now just use the git add logs/ command. Thus, the logs folder will be added to the repository, but the log files in that folder will be ignored.
I usually use this for folder uploads that need to exist, but I do not need the files that are in the same folder.
Git points to files, not directories, so it will not be possible to add an empty directory / folder.
There are some points I disagree with the @WallaceMaxters answer , as well as reply from @egomesbrandao also did not please me as a whole. I’ll give a quick explanation of how the folder and file schema of a git repository works and then show why the @egomesbrandao statement is correct and why the @WallaceMaxters solution answers the question.
I will also not stick to bare repositories, reading the response text should be done with that in mind.
git works by identifying files, from the root of the repository (the location where the .git directory is located). The identification of a file, however, is not made from the traditional form of conventional file systems, but is more similar to what Amazon uses in S3.
Then, for the% w /% of the @WallaceMaxters responses, the .gitignore identifies this file by the name git . It is so much that changes in positioning / filename /logs/.gitignore suggests that you have changed the file git to file x , regardless of whether the change was just a rename file within the same directory, or have moved to another directory maintaining the name, or even changing the name and directory.
This mode of file identification implies that there is no directory concept (within the internal ID of y at least). One of the impacts of this is that you do not have to worry about maintaining the directories. Moving all files from git to /outer/inner/deep implies that when the next /outer/inner is given, the clone folder will not exist. And you did not have to say it explicitly.
The absence of this concept of directories in /outer/inner/deep is the essence of @egomesbrandao’s response, as it is also the origin of one of the original questions of the question.
The solution proposed by @WallaceMaxters tries to make the most of this git mode of operation. Internally, folders do not exist. What exists is the handle of the file with bars in the middle. In contrast, by “extracting” these files and placing them in the actual filesystem, directories are created so that the “name with directories” is the same as the internal name used by git .
My point of disagreement with the @WallaceMaxters answer is: by giving git , you did not add the directory (since this concept does not exist), but ALL the relevant content within the directory pointed to. The git add logs , in this case, is a hidden file on Unix file systems, so the impression given is that the directory was created empty. To maintain the directory structure, any file would suffice. Hidden would be better.
The @WallaceMaxters solution also points to the issue of keeping the empty content of the .gitignore folder in the actual file system (with the exception of logs , of course). This is why the file chosen to “populate” the folder was .gitignore , because in addition to being hidden (ideal to make the directory exist) it also prevents the recognition of new files.