Git best practices on Acquia Cloud Site Factory

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 Acquia Cloud Site Factory code.

For more information about using Git, including clients and basic commands, see Using Git.

Feature branch workflow

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:

  1. A developer creates a new branch (based on the master branch) to start work on a new feature.
  2. When the work is completed, the feature branch is pushed back to the origin, which is the remote of the developer's forked repository.
  3. The developer opens a pull request against master, giving other team members the chance to review the developer's work.
  4. After the developer's work is accepted, it is merged into the master branch.

Larger teams should instead consider the Gitflow workflow as it provides better release management than the simpler feature branch workflow.

Gitflow 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:

  1. A developer creates a new branch (based on an up-to-date develop branch) to start work on a new feature.
  2. When the developer completes work, the feature branch is pushed back to the origin, which is the remote of the developer's forked repository.
  3. The developer opens a pull request against the develop branch, giving other team members the chance to review the developer's work prior to merging into the develop branch.
  4. After the pull request is approved and the features merged into the develop branch, a new release branch is created off of the develop branch.
  5. The development team continues to create feature branches off of the develop branch, while the release team prepares the release branch to add only what is necessary for the release.
  6. As part of releasing the code, the release branch is merged back into master.
  7. The 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.

Contact supportStill need assistance? Contact Acquia Support