In his Drupal4Gov webinar Using tools and Git workflow best practices to simplify your local development, Greg Lund-Chaix, Senior Infrastructure Engineer at Tag1, talks about some of the ways that teams struggle when they become successful and need to learn to scale. He recommends using some basic tools to make your workflow easier. The right tools in your environment can prevent big problems down the line with merge conflicts, code committed to the wrong branch, or other mistakes.

Git is one of the most common version control systems in use today. With a few tools, and a few best practices, you and your team can make your local environments easier and safer to use.

Rebasing

Learn to rebase. When you’re working on a feature it might take you a few hours, to several days or weeks. The longer you take working on a branch, the more chances your branch is out of sync with the rest of the code base. The cleanest way to prevent problems is to rebase. Rebasing checks where your branch diverged from main, pulls in all the changes, and replays your changes on top of them. Rebasing prevents cluttering up your commit history, too.

Here’s an example of how Greg works:

[laptop] ~ $ git checkout feature123-amazing-stuff
[laptop] ~ $ git pull --rebase origin main
[laptop] ~ $ git add my_amazing_module.module
[laptop] ~ $ git commit
[laptop] ~ $ git pull --rebase origin main
[laptop] ~ $ git push -u origin feature_branch

Greg starts his day by checking out his feature branch. Greg always works in feature branches, as one of his core four rules. He can’t be sure if anyone has committed code since he last checked this branch, so he rebases his branch against the main branch on his codebase’s origin. Everyone else’s changes are pulled in, and Greg’s changes are added back on top of them. Now, if someone has made changes to the same files Greg has, he’s able to see the conflicts before they go into the main branch. A pull --rebase does not add a merge commit, and keeps your commit history cleaner.

Now, Greg knows his changes are clean. During the day, he adds and commits more changes. Just before the end of the day, he rebases again, ensuring his code is as clean and safe as possible before he finally pushes it at the end of the session.

Git prompts for sanity

Anyone who has ever worked on a command line has felt the pain of doing something in the wrong directory, deleting the wrong file, or moving something to the wrong place. Your command line prompt can be a helpful indicator for where you are, what you’re doing, and the status of your local repository.

Git includes a script for showing your repository status in your command prompt. Download the git-prompt.sh file or look for it in your git source, and customize it to your needs. This prompt file does several helpful things:

  • Tells you what branch you’re on
  • Adds a red percent (%) sign when there are untracked files in the repository
  • Adds a red asterisk (*) when there's a changed file in the repository
  • Adds a green plus sign (+) when a file has been added using git add

These indicators flag that there is some change that has not been committed. This may be expected, but it may also be a sign that something has gone wrong - for example, if your indicators show up when you’re on the main branch.

Greg made a secondary script available for prompts, which indicates where you’re making the changes: locally, or on a server. If this might help you, download the servertype-prompt.sh script for yourself. This script depends on git-prompt.sh. Whether or not that prompt displays is an indicator for where you’re working.

Sniff your code

Unlike the more traditional network sniffer, which analyzes your packet traffic on the wire, a code sniffer reviews your code and checks it against a predefined standard. PHP_CodeSniffer “tokenizes PHP files and detects violations of a defined set of coding standards.”

Drupal developers are often familiar with the Coder module, written by Tag1 Senior Architect Doug Green, checks your Drupal code against coding standards and other best practices.

To include these in your codebase, add the following lines to your composer.json file.

composer require --dev drupal/coder
composer require --dev dealerdirect/phpcodesniffer-composer-installer

For a full tutorial on installing Coder and PHP Codesniffer, see Installing Coder Sniffer on drupal.org.

Coder module is designed to work with PHP CodeSniffer, making it easy to integrate with your continuous integration platform. Setting your team up with this kind of integration enables automated coding standard reviews on every pull request.

Other useful tools

Pre-commit hooks can run checks for you before you make a commit locally. You can set up a hook to run codesniffer before you commit - if your codesniffer fails, your commit fails, too! This can prevent some of the more obvious mistakes from even making into your local code. See an example Drupal pre-commit hook by Marco Marctino (mecmartini), or full documentation at pre-commit.

Tig is a visual command line tool that lets you see commit and log information for your repository. It has an interface that enables you to walk the list of commits, and see the details more easily.

Users who are less comfortable or familiar with the command line may find a graphical interface to be friendlier. Many GUIs are available for Git. If you’re struggling with the command line, check out a GUI and make your life easier.

About Drupal 4 Gov

Drupal 4 gov is an open source community for developers and IT professionals with an interest in making the government more open to open source.

It encompasses many open source projects but we have our beginnings in the Drupal project.

Drupal4gov offers:

Photo by MJ Tangonan on Unsplash