I can not stop reading this. And ‘so fresh, so full of information, I do not know. I’m glad that people actually write the smart way to show the different sides of him.
It is indeed my great delight to Think About your website Also fantastic to appreciate your current content right here
For Drupal Modules we are always using GIT. At today we are working on a Connect for Drupal and Shopware, and some more Shop-Systems.
Connect for Druapl and Shopware? Sounds very interesting. Some details to share already? Thanks
This post is exactly what I am interested. we need some more good information. Please add more good information that would help others in such good way.
Thx, good blogpost. Don’t know if you’re aware of, but since it wasn’t mentioned in the post: for doing adaptions on a module githubs fork and pullRequest functionality could be quite useful.
right Alain, though original drupal modules are usually not hosted on github…
I´ve not yet worked with Drupal – only with Contao CMS. Some of our clients have already Drupal installed, so I will give it a try!
I used to employ git-submodules a lot for the exact same purpose, i.e. pulling in contrib modules from drupal.org into sites/all/modules. Before the recent switch from CVS to git on d.o I had a script parsing the release history of selected projects and commiting new releases automatically to my repositories. I was then able to upgrade a module
using a simple git pull in the checked out submodule and committing+pushing it within the enclosing site.
However I abandoned the usage of git submodules recently because it caused too much confusion among colleagues. Having everything in one repository also simplifies deployment, especially when git or shell-access does not happen to be available on a target host (via git-archive). Note that it is no problem to still maintain some modules as a git
checkout locally. You may even add changed files from the git checkout to the main repository while keeping the exact history in a branch in the modules repository. Like that, submitting patches upstream remains straight forward.
For site maintenance I simply rely on drush.