OrganizedFellow

What files/folders should be added to .gitignore for regular development?

Recommended Posts

I recently just started using GIT in my daily workflow on other non-PW and static html projects, and got stuck today just as I was starting a new PW project, LOL.

My git terminology is probably wrong here, but where should I "git init"?

At the site root? Under "/site/templates/"?

Personally, I like to keep all my css, js and img folders at the root of my sites.

So if I "git init" at the root, I'd have to ignore lots of core folders and files, right?

And I'm thinking I gotta ignore the cache as well.

What files/folders should be added to .gitignore for regular development?

Share this post


Link to post
Share on other sites

If you are version controlling your entire /site/ dir then you'd definitely want to exclude cache and sessions. My opinion is that if you version control this stuff, just do it on  /site/templates/, and let each module be under its own version control (or use Modules Manager). I don't think it's worth versioning /site/assets/files/ for instance, because any change of versions would disconnect it with your database, which is something you wouldn't want.

  • Like 3

Share this post


Link to post
Share on other sites

I'm building up a ProcessWire boilerplate for quick starting the post-installation work. I've got a basic .gitignore which covers ProcessWire ignores, as well as other ignores for the rest of the project.

You can find it here:

https://github.com/fixate/pw-boilerplate/blob/master/!root/.gitignore

It's based off of Ryan's SkyScrapers .gitignore:

https://github.com/ryancramerdesign/ProcessWire/blob/master/.gitignore

but keeps certain files, such as .htaccess (we use a custom one which extends ProcessWire's with H5BP's), in the repo so that they are available to team members. For this same reason, we never ignore .gitignore itself; it must be available to all team members.

You can safely remove the styleguide and Grunt stuff if they're not part of your projects.

  • Like 6

Share this post


Link to post
Share on other sites

1) As Ryan proposed It seems to be wise to init a repo in templates folder. But there are files higher in the structure that influence site behavior a lot and need to be version cоntrolled, like config.php and .htaccess. Do you know of a way to include those?

2) It would be great to know if someone installed or upgraded core or modules. Maybe there could be a way to make a list of installed modules with something like git hooks (or a PW module) and their versions and put them in the templates folder somewhere. The same could be used for templates/fields/pages, but I am not looking that far yet. Did anyone try that?

If that is possible there would be no need to mess with complicated .gitignore and init repo in the installation root.

Share this post


Link to post
Share on other sites

If that is possible there would be no need to mess with complicated .gitignore and init repo in the installation root.

# exclude the whole big-data-stuff
/site/assets
/site/assets/*

wire
/wire/*

index.php
.htaccess
/.*/
/.*

Where's the mess?

  • Like 2

Share this post


Link to post
Share on other sites

Here's mine:

site/assets/cache
site/assets/sessions
site/assets/logs
site/assets/files
site/config-dev.php
  • Like 2

Share this post


Link to post
Share on other sites
@Wanze Do you version comtrol your wire folder?

Yep.  :)

  • Like 1

Share this post


Link to post
Share on other sites
On 25/02/2013 at 9:49 PM, ryan said:

I don't think it's worth versioning /site/assets/files/ for instance, because any change of versions would disconnect it with your database, which is something you wouldn't want.

What does it mean "any change of version" here? Any change of the files? Would it be ok to version control the files assets if I am also committing the database?

Share this post


Link to post
Share on other sites

Hello @microcipcip,

I believe Ryan meant any change of the files. It is not recommended to track assets or uploads folders, because they can easily bloat your commit history and even worse you could grow a repository over 1 GB. Tracking the database would require you to make always dumps of it. Even though you could automate this, I also don't recommend it, because it could bloat your commit history too.

If you need inspiration of a .gitignore file, there is a popular GitHub-repository with templates for other systems. Maybe ProcessWire could be added too.

Regards, Andreas

  • Like 1

Share this post


Link to post
Share on other sites

Okay, ATM I have ignored the assets folder processwire core, all seems good :). Why do you think that committing the database would bloat the commit history?

Share this post


Link to post
Share on other sites

Perhaps working solo and on only one machine would be ok for not committing database versions, but working with multiple devs would make db updates a nightmare if they weren't committed to a repo. Working from a single remote database is painfully slow, and as soon as you have no internet, your work stops there and then. At Fixate we've always versioned our db's for ProcessWire sites. Adding db exports to a repo is not ideal, but in terms of pragmatic workflow it's the fastest way to keep a project moving efficiently.

The alternative would require a manifest or generator that would check if the correct fields are present on a database, and programmatically insert them (like Rails migrations). This would be the best way to go, as you're versioning your schema, as opposed to your data, but in terms of flexibility of what your admin looks like, you're going to have to manage enormous schemas for each template and field if you're to ensure the best UX in the admin for your clients.

We've automated MySQL exports and imports with Gulp: https://github.com/fixate/generator-fixate-pw/blob/master/app/templates/gulp/tasks/mysql.js

  • Like 1

Share this post


Link to post
Share on other sites
39 minutes ago, larrybotha said:

The alternative would require a manifest or generator that would check if the correct fields are present on a database, and programmatically insert them (like Rails migrations). This would be the best way to go, as you're versioning your schema, as opposed to your data, but in terms of flexibility of what your admin looks like, you're going to have to manage enormous schemas for each template and field if you're to ensure the best UX in the admin for your clients.

Or use my migrations module, to kinda get the best of both worlds. The ease of the ProcessWire API with the ability to have migrations run/downgraded as needed.

  • Like 4

Share this post


Link to post
Share on other sites
On 10.11.2016 at 2:07 AM, microcipcip said:

Okay, ATM I have ignored the assets folder processwire core, all seems good :). Why do you think that committing the database would bloat the commit history?

This is just my opinion, as I am working most of the time solo on my repositories. If I would work collaborative on a project I would probably track the database changes too or try the Migrations module. ;)

Share this post


Link to post
Share on other sites

Okay, thanks all for your suggestions. I'll have a look at the migrations module when I have time, it certainly looks like a nice solution but I need to read it carefully to avoid losing content.

Share this post


Link to post
Share on other sites

Picking up on this old thread. If it's considered bad practice to version control assets, how do you share them between devs/environments?

Share this post


Link to post
Share on other sites

@onjegolders ye that's a bit of a pain. At Fixate we generally use placeholders until real content is added. Once real content is added, if someone needs the content for anything specific (usually the devs don't need all assets to work on the site) we'll Slack each other the assets.

Once a site is on a staging environment it gets easier to manage, as final content is usually added there. We use rsync to sync remote assets to local folders, and sync site files to the remote using Gulp:

https://github.com/fixate/generator-fixate-pw/blob/master/app/templates/gulp/tasks/rsync.js

I'd be interested to hear how others handle it, but yup - don't commit assets or generated files (*.css, *.js, minified images, etc) to your repo - your repo should contain only dev and working files; a build process should be responsible for generating production files. Clean repos, and clean commit histories :)

  • Like 1

Share this post


Link to post
Share on other sites

Thanks @larrybotha, having spent a fair amount of time with Craft, I think this is one area where having files tied to pages makes things more difficult. With Craft it is possible to have you assets exclusively in say an S3 bucket, so your assets will always stay the same and accessible across environments/users

mys3bucket.com/images/featured/featured1.jpg

etc

If I ever need to create a new site to access those images or a new dev needs to set up, they can just get started straight away.

  • Like 1

Share this post


Link to post
Share on other sites

@onjegolders ye, that's a far superior way of working with uploaded assets. I still need to take a look at S3 integration with ProcessWire, but that would alleviate a lot of headaches.

  • Like 1

Share this post


Link to post
Share on other sites

Yep, I've no doubt Ryan and the most senior devs here have their very strong reasons for keeping assets so tied to pages and I very much take their word for it but from a purely dev and client point of view, I have very much enjoyed using assets in a centralised place (meaning easy reuse, it gets tiring having to drag images of the front-end to the desktop to upload them back up again on another admin page), and the bonus of being able to pass all this off to S3 or equivalent would be a huge boost for my productivity.

Share this post


Link to post
Share on other sites
1 hour ago, onjegolders said:

I have very much enjoyed using assets in a centralised place (meaning easy reuse,

Sorry, OT: I'm guessing that's why you are testing Media Manager?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.