All the files a stranger would need to have your site running. Meaning I can clone your repo and run the server with that directory as the root and it just works.
Explaining to someone new to Git this way can be a little misleading. For instance, if you cloned my react app into a folder on a fresh computer, it wouldn't
just work, you'd have a lot system configuration and need to know how to install those app dependencies, and even then, there are typically assets or configuration that you keep out of source control. For a project like WordPress (or any other typical WAMP/MAMP/LAMP stack project), you wouldn't have the LAMP executable, database, PHP configuration, etc., in your repository.
--
sturmdogg, the idea of source control is, at it's simplest, to track changes to your code in a project. It's really nothing more than that at it's simplest.
Distributed source control using something like Git or using a hosted platform like Github (the most common these days) adds a lot more features and enables you to collaborate on projects a lot more easily, but at base, source control is just tracking changes to code over time. You can add anything you want to source control, but
usually source control systems like Git, SVN, Perforce, and others, generally focus on tracking only
code changes. Code is something that can be tracked very quickly and efficiently by a source control system, where as binary files like images, audio clips, word documents, PDFs, and other media-rich file formats really aren't tracked efficiently by source control. Usually those file formats have their own ideal change management systems, like for instance a Digital Asset Manager might be used for images or design files, or Adobe and Microsoft have their own internal systems for tracking changes to a Word file or PDF, etc. But systems like
git are made for tracking code changes.
Along with binary files, most people usually do not track their database in source control. There's a long list of reasons why but usually it comes down to how efficient source control could track a large database, which is simply not very efficient. What you really want to track, in that case, is how another developer would connect to your database
or be able to copy the schema of your database (the structure of it) so that they could create their own. In the first case, the "How another developer would connect to your database," this is usually as simple as committing a configuration file, and for the second case, most applications define their database schema somewhere in the app.
For your job application, it's unlikely that you've contributed much code to community/open source repositories at this point, but you can add your source code for specific projects as individual git repositories to something like Github or Bitbucket. Remember that these are usually *public* repositories, so you do have to be careful to not add files to the repo that have sensitive data in them (for instance, if it's a WordPress site, you wouldn't want your wp-config.php to be in the repo because then your database password would be public...).
Depending on the project, someone has probably written a "Best way to add *blah* to Git," for instance, "Best practices using Git and WordPress" or something. I work on a lot of WordPress projects for freelance and my rule of thumb is that I really only commit the specific parts of the project that I'm working on. So, this is usually just my custom theme that I develop and then any custom plugins. If I've added a plugin from the WP plugin repository, I don't add that to the git repository. You
could but it's kind of a waste IMO because WordPress stores plugin activations in the database, so restoring the plugins for a WP site is usually more effective using the built in tools and plugin repository. I also don't store any media files, plugin dependencies (like say a backup file, etc) to the source control repository because source control isn't great at tracking changes to binary files and it's more or less a waste of storage or could be done better using something else.
