Jump to content

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


OrganizedFellow
 Share

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?

Link to comment
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
Link to comment
Share on other sites

  • 8 months later...

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
Link to comment
Share on other sites

  • 1 year later...

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.

Link to comment
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
Link to comment
Share on other sites

  • 1 year later...
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?

Link to comment
Share on other sites

  • 2 weeks later...

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
Link to comment
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
Link to comment
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 5
Link to comment
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. ;)

Link to comment
Share on other sites

  • 8 months later...

@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
Link to comment
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
Link to comment
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.

Link to comment
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
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...