denkwerk TechTalk
Git features in PhpStorm
In hands-on PHP development, it can often be difficult to track changes and instructions between developer:inside and reviewer. With the PhpStorm IDE and a little hygiene in commit creation, the process can be greatly simplified.
PHP development with PhpStorm
PHP development is basically possible with any text editor, of course. For large projects, as they are everyday at denkwerk, it is important to use a development environment including the versioning Git. This allows developers, reviewers and project managers to make code additions and changes. A powerful tool for this is PhpStorm, which we also use at denkwerk.
However, the use of a powerful IDE is not everything: Git commits and their commenting should receive special attention to make it easier for developers to work on their own and other people's projects. PhpStorm offers a variety of possibilities for this, as denkwerk Software Developer Miguel Franken summarizes in the current TechTalk.
The A and O: Commits cleanly hold
Basically, various methods exist to keep commits and their messages clear and traceable.
"The commit history should always tell a story," says Miguel, who offers tips on how developers can ensure that commits are entered in a clean and traceable manner. Creating a clean commit history is a crucial factor – and the starting point for traceable work in the team.
"Complex projects have a lot of moving parts: you update a lot of places, places are added or deleted. With a clean history, it's much easier to track how we got to that point."
Atomic commits: making collaborative work more traceable
That's why Miguel advises making what he calls Atomic Commits: When developers make many changes in multiple places in the code, they tend to look at the big picture – and maintain the entire code as one commit. The idea behind atomic commits is to set each change as a separate commit and comment it. At the same time, only those commits that are relevant should be maintained.
This has three decisive advantages: On the one hand, code changes can be better tracked later, and on the other hand, this approach also enables third parties - such as reviewers or other developers – to understand changes. At the same time, atomic commits make it easier to search for bugs in the code. This automatically results in a "clean" commit history from the various processes.
Commit messages as an informative supplement
As support of this technology it is meaningful to attach value to the Commit-Messages, thus the description of the changes: Here all developers record which changes they have made with the respective commit. It is important to be as precise and concise as possible.
"Developers should ask themselves: what are the changes I made in these files?"
Commits: more complex messages for more complex changes.
A typical commit message would be "Update X to Y" or "Change Color of Element". Of course, the messages may be more complex if there are more complex changes. The commit message must contain all the information to facilitate the review.
To make the changes and messages easy to read and understand, it also makes sense to adhere to previously defined conventions. On the one hand, generally applicable rules can be used - such as formulating the commit message in the imperative. In addition, development teams should define common guidelines: These rules ensure that all important information is included and make it easier to track commits. After all, Miguel joked about the different ways software developers work, "one man's beauty is another man's evil hack."
Interactive rebase for a tidy commit history
To keep the commit history clean, the IDE PhpStorm offers some practical functions: For example, commits can be subsequently changed, added to, moved or deleted using "Interactive Rebase". Miguel recommends making these changes locally before pushing: "Don't push until you're happy with your work."
Changes to commit messages should be recorded by means of so-called "amendments", i.e. additions to the commit message. Here it is not necessary to comment on small things like spelling corrections to the previous message. However, more complex additions or changes can also be recorded in this way. This enables reviewers and developers to track code changes at any time.
