If you have seen me speak at events in recent years, most likely you have heard me mentioning CaptainHookPHP as being my favorite git hook manager. I really like its flexibility and have covered some of our project setups in some blog posts.
Since we are currently moving to DDEV to standardize our Docker development setups, I was wondering how easy it will be to add my favorite Git Hook Manager CaptainHookPHP to the setup.
Captain Hook is my primary choice when it comes to managing Git Hooks. For a few days, Captain Hook supports PHP 8.2 - the latest and greatest PHP release.
For a few internal applications, we manage downstream forks with some customizations tailored to our needs. We try to contribute as many changes to upstream as possible, but for some cases, this does not make sense, e.g. when we customize user synchronization processes.
About code quality, automation and git hooks
These days we get more and more in situations where we have to push our code into Git repositories of our customers, either because the customer wants access to the source code or because we are working closely with their in-house team. Maintaining our own local copy of the source code and constantly keeping our copy in sync is a no brainer with Git.
Back at MageTestFest in Florence, I introduced the audience to a tool called Captain Hook for managing Git hooks. In the QA section of my talk, the question was raised why I have not recommended to use GrumPHP. A valid question since all the QA tools I talked about are already supported by GrumPHP out-of-the-box.
Sometimes you run into this situation when a git pull will respond with Merge conflict in config.php. How to solve this issue in a proper way? Let's have a look how other people solve similar issues, namely my friend Mr. Rafael Dohms. Quite a while ago he blogged about a similar problem on how to solve conflicts in Composer's lock file. This is what I learned from his blog post:
Long ago I started to globally .gitignore all the things. Recently I ran into a few issues with setting up Sencha projects via SenchaCmd. In my global .gitignore file I have a setting to ignore the vendor folder which perfectly makes sense in a Composer setup. As a side-effect this means that in a Sencha project the folder resources/themes/vendor/ will not be added to the repo. The work-a-round to avoid this is easy and simple. Add the following line to your global .gitignore file:
Recently we were in the need to create (and host) an own npm module. Setting up a private repository with sinopia seemed like a bit too much work for hosting just a single npm package. So I decided to use the built-in functionality of npm to directly refer to a git repository in the package.json file. This worked fine on "my machine" but failed on my co-workers machine. It turned out that we were both using the same version of nodejs and npm but we were running different versions of git. I had a recent version of git running. My co-worker's git version was pretty old (1.7.x). I advised that we should upgrade git any try again. And guess what, after the upgrade npm install worked perfectly fine.