7

We have an internal discussion going here and we are somewhat torn on the best practice for using .gitignore on projects that contain a lot of files (like a CMS).

Method 1

Method 1 would be to purposefully .gitignore all files that come standard with your build. That would generally start like:

# ignore everything in the root except the "wp-content" directory.
!wp-content/

# ignore everything in the "wp-content" directory, except:
# "mu-plugins", "plugins", "themes" directory
wp-content/*
!wp-content/mu-plugins/
!wp-content/plugins/
!wp-content/themes/

# ignore these plugins
wp-content/plugins/hello.php

# ignore specific themes
wp-content/themes/twenty*/

# ignore node dependency directories
node_modules/

# ignore log files and databases
*.log
*.sql
*.sqlite

Some staff members like this approach since if you create something outside of the standard files, for example like a /build folder, then it would automatically be detected for inclusion. However, writing custom theming and plugins require you to add a few layers to this file to "step in" to the folders you want to keep, and generally, the file is a bit messier to read.

Method 2

Method 2 ignores everything, and then you whitelist what you want in the repo. That would look like

# Ignore everything, but all to descend into subdirectories
*
!*/

# root files
!/.gitignore
!/.htaccess.live
!/favicon.ico
!/robots.txt

# theme
!/wp-content/themes/mytheme/**
/wp-content/themes/mytheme/style.css # Ignore Compiled CSS
/wp-content/themes/mytheme/js # Ignore Compiled JS

# plugins
!/wp-content/plugins/my-plugin/**

# deployment resources
!/build/**

Some staff like this since it's cleaner, you have to purposefully add something (which makes accidental adds harder), and it also in effect shows you your .git folder structure.

What is the best practice? Which method do you enjoy and would you recommend doing one over the other?

hdwebpros
  • 528
  • 3
  • 7
  • 20
  • Why do you say "as a dev"? Git isn't just for developers; it's not a great solution, but it's the best one for all the other things. –  Mar 31 '20 at 05:11
  • 1
    You may also want to check out http://gitignore.io/ to easily create `.gitignore` files covering all your files and folders – HelloBlob Apr 06 '20 at 18:45
  • @HelloBlob Using that would be Method 1 in what I laid out. My issue with that option would be having a .gitignore file like: gitignore.io/api/joomla. Plus, if you have the entire CMS in your repo, there's the small chance that on each upgrade, you'd have to either explicity ignore another file or you'd have things in your .gitignore file that you don't need to ignore anymore. Method 2 doesn't have those issues. – hdwebpros Apr 07 '20 at 12:30

2 Answers2

4

The second method is the best practice, when it comes to exlude some folder contents of gitignore rules.

It better reflect the following rule:

It is not possible to re-include a file if a parent directory of that file is excluded.

To exclude files (or all files) from a subfolder of an ignored folder f, you would do:

f/**
!f/**/
!f/a/sub/folder/someFile.txt

Meaning: you need to whitelist folders first, before being able to exclude from gitignore files.

It is clearer, shorter (unless you have a large number of folder to whitelist)

What if it is a Joomla install with a large amount of directories and files?
Or what if a core upgrade adds new files or folders

Don't forget you can have multiple gitignore files, one per folder.
That means you can mix and match both approaches.

And you have:

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • What if it is a Joomla install with a large amount of directories and files? Or what if a core upgrade adds new files or folders -- that's more that you'd have to worry about. I guess there are pros and cons to both. I appreciate your feedback. – hdwebpros Mar 31 '20 at 00:28
  • @hdwebpros I have updated the answer to address your comment. – VonC Mar 31 '20 at 04:26
  • To make sure we are on the same page... my first answer would be to create a large .gitignore file like here: http://gitignore.io/api/joomla. My second answer would be to make a simple gitignore file with the "# Ignore everything, but all to descend into subdirectories". (I've updated my question to show the methods more clearly) – hdwebpros Mar 31 '20 at 11:55
  • @hdwebpros Yes, although in your second option, I don't know why you exclude build: if this folder includes only build elements (generated automatically during a build), you can ignore it in a Git repository. If "build" is a folder with resources needed for the build to complete, then yes, it can be versioned. – VonC Mar 31 '20 at 12:06
  • The second option (Method 2) only shows files/folders we are including -- it excludes everything else. We want to include the build folder in Method 2. We don't use the "build" folder to store compiled assets. We use that folder typically for assets used to build the app. (scss, pre-compiled js, package.json, etc). – hdwebpros Mar 31 '20 at 13:16
  • @hdwebpros Perfect, then build belongs indeed to what you want to include. – VonC Mar 31 '20 at 13:18
  • Perfect. I'll consider Method #2 the way to go. I wish more people would have chimed in. – hdwebpros Mar 31 '20 at 16:07
0

The ideal .gitignore file, is the one that does not exist.

For some reason, you're deeply intermingling files you want to track via source control, with files you DON'T want to track.

This, I think, is the source of your sadness.

You are mixing git's intended purpose, which is versioning of programmer-edited files, with deployment, which is intended to get the files where they belong in the correct directories.

Your question is not clear, as to whether you think the Wordpress core files should be versioned. I'm assuming not, since that's how you've set up your .gitignore.

Your question is also not clear, as to whether you are deploying a web site, or shipping plugins as a product. Those are both different use cases, and they require different types of versioning. If this is a deployed web site, you SHOULD be versioning Wordpress along with everything else. If you are shipping a plugin or a theme, then you should have a test suite of plenty of different Wordpress versions to test against.

I think your source control system should be set up, solely to track just the plugins/* and/or themes/* files that go into your distribution. Zipping that folder should give you the plugin asset that your customers download.

To debug your plugins, there should be a deploy step in your IDE that copies each of those tracked files, into a Wordpress install at a location you choose. This permits you to more easily test against different Wordpress versions.

You're reducing workflow problems, to trying to choose a .gitignore. Fix the problem at the root by getting the workflow right.

johnwbyrd
  • 3,432
  • 2
  • 29
  • 25
  • There's no sadness. I'm just curious to the best method for using gitignore. I'm personally more for option 2, where you intentionally include what you need. Not the other way around – hdwebpros Apr 06 '20 at 23:03