You should treat your Git repository that is hosted by Acquia as a repository for build artifacts created as part of your continuous integration (CI) setup, with your chosen workflow determining how direct changes are prepared for inclusion through CI. Depending on the size of your team, Acquia recommends that you use either the Feature branch workflow or the Gitflow workflow as you develop and maintain your Site Factory code.
For more information about using Git, including clients and basic commands, see Using Git.
The feature branch workflow
is a development style that is well-suited for small teams, which
encourages having all feature development work take place on a dedicated
branch of your Git repository, instead of committing locally to the
standard master
branch. A sample workflow is as follows:
master
branch) to
start work on a new feature.origin
, which is the remote of the developer’s forked repository.master
, giving other
team members the chance to review the developer’s work.master
branch.Larger teams should instead consider the Gitflow workflow as it provides better release management than the simpler feature branch workflow.
The Gitflow workflow
extends the feature branch workflow by requiring developers to submit
pull requests against a develop
branch which serves as an
integration branch for new feature, while maintaining a stable
master
branch that remains in a good state.
Here is a description of a sample workflow based on Gitflow:
develop
branch) to start work on a new feature.origin
, which is the remote of the developer’s forked
repository.develop
branch,
giving other team members the chance to review the developer’s work
prior to merging into the develop
branch.develop
branch, a new release
branch is created off of the
develop
branch.develop
branch, while the release team prepares the release
branch to add only what is necessary for the release.release
branch is merged back
into master
.develop
branch is rebased onto master
to incorporate the
changes made in the latest release.In this development strategy, any needed hotfixes are merged directly
into a hotfix
branch, which can then be merged with master
.
The underlying principle: production is an artifact of development. Put differently, the things that you need to run your Drupal site in a production capacity are not the same things that you need to develop your Drupal site locally.
For instance, you may use a suite of tools like DrupalVM, Documentation, CHANGELOGs, Unoptimized Images, PHP CodeSniffer, SASS, etc., to develop your Drupal application. These are tools used to produce your site, but they are not your site, and hence these things do not belong on your production server.
The build process is intended to take your development “source” code and produce an artifact that is production ready. Often, this means removing development-only packages, sanitizing your codebase, and optimizing your application for performance.
Important
For more information about the workflow to build a complete Drupal application, see Deployment workflow.