More Recipes - Git Recipes - page 542

outputs the changes that can be regarded as problems with white characters. And re-
member that one of the best and easiest solutions to prevent all problems with line end-
ings is to use the .gitattributes file—defining line endings on a per pattern
basis. Using the simple rule * eol=lf , you can avoid all problems concerning line
endings. This solution was presented in Recipe 13-7.
Recipes 13-8, 13-9, and 13-10 present the three most typical problems that you can
solve by defining appropriate rules to ignore files. The first problem concerns the bin-
ary files that are automatically generated by various tools. Here are the examples:
• The files generated during compilation: *.o , a.out , *.exe , *.lib
• Cached configuration generated when the application is executed; it can
be stored in some special directory, such as cache/
• Dependencies—the external libraries embedded in the project; they can be
stored in some specific directory, such as vendor/
Because all developers will from time to time generate all of the above files, the best
solution for these files is to ignore them using the .gitignore file that is committed
with the project.
The second case concerns the files that contain some private information. It can be
the configuration with credentials to access external resource, such as database. Here
again all the developers and users will struggle with the same problem: how to avoid
inadvertent publication of these sensitive data. Thus, the rules to exclude these types of
files should be also stored in the .gitignore file that is committed in the repository.
The third case concerns the private settings of every developer. I use specific tools
that create specific files inside the project. In this case it makes no sense to commit the
rules into the repository. Thus, to ignore the files and directories generated by the tools
that I use, I can either use the .git/info/exclude file stored within the specific
repository or the user's global .gitignore file stored in his or her home directory.
Two final recipes showed how to work with tags and with the $ git archive
command. Remember that git offers two different types of tags: annotated tags and
lightweight tags. Annotated tags are stored in the .git/objects database. They
contain detailed information about who, when, and why created the tag. Lightweight
tags are just aliases for referencing commits. As in the case of branches: there is no in-
formation who, when, or why created a lightweight tag or a branch. Some projects,
such as jQuery, use lightweight tags. Others, such as Symfony, use annotated tags. The
choice is up to you, although because annotated tags contain author, date, and com-