Each release will have this name pattern [drupal-version]-profile-release]. Example 8.0.1-1.0. Different releases may exist for the same profile version (so only the Drupal version will change).

Patches that are submitted from D.O. or other places should be commited with the files on git!

Only the Project manager should be able to merge.

We are starting development always from develop branch except if there is a hotfix.

When we create a pull-request you have to commit on the same pull-request (using a local branch) and when ready merge it.

After each successful release there will be a new make file from existing files/configuration.

Modules that are used for development (devel, masquarade etc) will be commited to Github but they will not be imported to the make file except if they are requirements for any of the modules of the distribution.

If you need a publish a branch that should NOT be merged use this naming pattern no-merge-[branch_name].

If you want to see what are the raw git commands running after a git-flow command add the --showcommands argument at the end.

Avoid pushing online too many similar branches (eg branches of Content types). First find the working formula for a type of branch and then copy this successful methodology to other. Event then there is no need to create a dozen of branches online.

Limit the subject line to 50 characters, Github and many other tools use the title on their UI.

Capitalize the subject line.

Do not end the subject line with a period!

Use the imperative mood in the subject line.

Wrap the body at 72 characters.

Use the body to explain what and why vs how.

In practice in order to open the editor to write the commit do not use the -m flag because it prevents from opening the editor. Instead use:

git commit which opens the default editor for git.

To change the default editor (let’s say to vim) type:

git config --global core.editor "/usr/bin/vim -n -w"

A masterpiece of a commit may look like this:

Summarize changes in around 50 characters or less
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.
Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded
by a single space, with blank lines in between, but conventions
vary here
If you use an issue tracker, put references to them at the bottom,
like this:
Resolves: #123
See also: #456, #789

Avoid committing “at the end of the work day”, or “whenever I feel like it”, or whenever a batch of fixes are complete. This way the VCS is just a backup of your work.

Similar to the definition of “Atomic design” the “Atomic commit” refers to a commit of code that can be reused, ignored, separated etc. On the atomic development approach we make changes through commits as small and “atomic” as possible.

Here are the principles of atomic commits:

Focus on one feature/fix etc at a time.

Create a separate branch for each task that will finish up as a group of commits. git-flow in the resque.

Commit each fix or task as a separate change.

Only commit when a block of work is complete. Don’t commit half-done work.

$ git status
Modified: contact.html
Modified: contact.php
$ git add -p contact.html
# Shows the first changed hunk in the file 'contact.html'
# and then asks you if you want to stage it or not!
$ git commit
# Opens the default git editor so you can create the commit message.
# Add the commit but do not push!
# Continue with another commit.
# When ready push.

For the dump database (without the backup_migrate module) avoid compressing the sql file. If you have to (eg the file is too large) use the gzip compression only. Example: livedb-2016-01-29T14:04:46+02:00.sql.gz

We cannot have VCS for database files.

User generated public and private files

Best option is to keep these files on a separate filestorage out of Drupal.

User generated files (eg sites/default/files) should be backup separately from the database.

We cannot have VCS for these files.

Restoring Backups

Always take a backup of current site (database dump, database from backup_migrate or backup_db, public/private files) before restoring a backup!

Never restore on the live site before testing the backups on a copy of the live site!

If a backup causes errors add an issue on GH and explain/ask for help.

Avoid taxonomy term reference fields! Instead use Entityreference fields with a Content type that will be used as a “taxonomy”.

Labels should not be displayed inline but blocks (display: block)

Fieldsets should be avoided. If not they should be open by default.

All fields require a Description to inform the user about their need.

No field should be shared. Never reuse fields except if a field needs to be the same across content types (eg a SKU)!

Display view modes should be generic for all Content types and not specific (eg event_full)

Machine names of Content types and fields should disallow name conflicts (eg nameone and nameoneplus may cause issues)

Fields machine name should follow this pattern for the machine name: field_[content_type_machine_name]_[short_name]

Content types, Views and Custom Blocks should follow this pattern for the machine name: [machinename]. That means you should use only letters and no special character or space. Machine names must be short but descriptive. Avoid very generic machine names or names that have been used already on the site even for another type of functionality (Views, Content types, Blocks, Plugins etc).

Better do NOT use the default (core) Body field but a custom one for each CT. Body field may break our sass patterns and automated tests since it doesn’t follow the machine name pattern described above.

According to the above we are supposed to use Entityreference instead of Taxonomy Term reference.
This is the rule except if there are cases that are met.

These cases are:

We need a web page (views) to show the referenced items (taxonomy built-in option)

We need a related functionality that works only (or better) with Taxonomy (eg search_api)

We don’t need revisions, publishing options and other things that are possible only with Content Types.

So, if 2 or more of the above cases are in need then we could discuss to use Taxonomy.

Field description best practices.

Write the description for the end user of the website not for the developers.

First of all describe what is the field about.

Write any special (technical) requirements (eg the minimum image dimensions).

At the end show real examples of the value(s) that should be used.

Let the user know if the field will not be published.

Let the user ask for help if she does not understand what is the field about (eg link to a wiki).

Keep the description pattern solid across the fields.

Don’t use <p> inside a description! Use only <br> to change lines.

Don’t write details about things that will be handled from Drupal on submission (eg that a field is required).

Link (href) to another internal page should be relative, should contain a title and open in a new window.

Example of an image field description.

This image will be used on the top of the page and it will have a 100% width.
<br>Best image dimensions is width: 1200px, height: 260px.
Larger or smaller images will be cropped (or stretched accordingly) to these dimensions.
<br>You can see the usage of the image on the <a href="/internal/styleguides#hero-image" title="hero image real example" tagret="_blank">Styleguides</a>.
<br>Get an image with such dimensions <a href="/path/to/1200_260/image" target="_blank" title="1200px*260px image">here</a>.

Before adding an external library/dependency check if it is already available (here is a list of the necessary 3rd party libraries for Core ). Do not confuse this with the Core libraries which is used to load the above libraries within Drupal.

Prefer tiny and specific libraries.

Check the library popularity on its official repository. Avoid libraries with no traffic at all.

If multiple release sources (eg packagist, apt-get etc) are available for the library prefer Github which is most of the times the development source.

Always use a release of a library (if available) and not a generic branch.

If a library needs to be loaded with composer add it without the helper module composer_manager but with core composer.