OrganizedFellow Posted February 24, 2013 Share Posted February 24, 2013 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 More sharing options...
Nico Knoll Posted February 24, 2013 Share Posted February 24, 2013 I always add ".gitignore" itself and ".DS_Store" Link to comment Share on other sites More sharing options...
OrganizedFellow Posted February 24, 2013 Author Share Posted February 24, 2013 I always add ".gitignore" itself and ".DS_Store" What about the cache folder and sessions? Link to comment Share on other sites More sharing options...
ryan Posted February 25, 2013 Share Posted February 25, 2013 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. 3 Link to comment Share on other sites More sharing options...
larrybotha Posted November 5, 2013 Share Posted November 5, 2013 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. 6 Link to comment Share on other sites More sharing options...
Ivan Gretsky Posted July 29, 2015 Share Posted July 29, 2015 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 More sharing options...
LostKobrakai Posted July 29, 2015 Share Posted July 29, 2015 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? 2 Link to comment Share on other sites More sharing options...
Wanze Posted July 29, 2015 Share Posted July 29, 2015 Here's mine: site/assets/cache site/assets/sessions site/assets/logs site/assets/files site/config-dev.php 2 Link to comment Share on other sites More sharing options...
Ivan Gretsky Posted July 30, 2015 Share Posted July 30, 2015 @Wanze Do you version control your wire folder? Link to comment Share on other sites More sharing options...
Wanze Posted July 30, 2015 Share Posted July 30, 2015 @Wanze Do you version comtrol your wire folder? Yep. 1 Link to comment Share on other sites More sharing options...
microcipcip Posted October 30, 2016 Share Posted October 30, 2016 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 More sharing options...
AndZyk Posted November 9, 2016 Share Posted November 9, 2016 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 1 Link to comment Share on other sites More sharing options...
microcipcip Posted November 10, 2016 Share Posted November 10, 2016 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? Link to comment Share on other sites More sharing options...
larrybotha Posted November 10, 2016 Share Posted November 10, 2016 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 1 Link to comment Share on other sites More sharing options...
LostKobrakai Posted November 10, 2016 Share Posted November 10, 2016 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. 5 Link to comment Share on other sites More sharing options...
AndZyk Posted November 13, 2016 Share Posted November 13, 2016 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 More sharing options...
microcipcip Posted November 13, 2016 Share Posted November 13, 2016 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. Link to comment Share on other sites More sharing options...
onjegolders Posted July 24, 2017 Share Posted July 24, 2017 Picking up on this old thread. If it's considered bad practice to version control assets, how do you share them between devs/environments? Link to comment Share on other sites More sharing options...
larrybotha Posted July 25, 2017 Share Posted July 25, 2017 @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 1 Link to comment Share on other sites More sharing options...
onjegolders Posted July 25, 2017 Share Posted July 25, 2017 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. 1 Link to comment Share on other sites More sharing options...
larrybotha Posted July 25, 2017 Share Posted July 25, 2017 @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. 1 Link to comment Share on other sites More sharing options...
onjegolders Posted July 25, 2017 Share Posted July 25, 2017 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 More sharing options...
kongondo Posted July 25, 2017 Share Posted July 25, 2017 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? Link to comment Share on other sites More sharing options...
onjegolders Posted July 25, 2017 Share Posted July 25, 2017 Hi @kongondo, yes indeed Link to comment Share on other sites More sharing options...
dragan Posted July 25, 2017 Share Posted July 25, 2017 I just stumbled upon this collection of .gitignores: https://github.com/github/gitignore Should we add a PW default .gitignore file there? 2 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now