---
title: "Git best practices on Site Factory"
date: "2024-02-14T06:18:38+00:00"
summary: "Optimize your Git workflow on Site Factory with expert best practices. Learn feature branch and Gitflow strategies for efficient team collaboration and seamless code management."
image:
type: "page"
url: "/site-factory/git-best-practices-site-factory"
id: "f018b516-c36b-4864-afe0-9eabf1a24ed7"
---

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](#acsf-feature-workflow) or the [Gitflow workflow](#acsf-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](/acquia-cloud-platform/develop-apps/repository/git).

Feature branch workflow
-----------------------

The [feature branch workflow](https://www.atlassian.com/git/tutorials/comparing-workflows#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](#acsf-gitflow-workflow) as it provides better release management than the simpler feature branch workflow.

Gitflow workflow
----------------

The [Gitflow workflow](https://www.atlassian.com/git/tutorials/comparing-workflows#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`.

Production is an artifact of development
----------------------------------------

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 can use a suite of tools like Lando, Documentation, CHANGELOGs, Unoptimized Images, PHP CodeSniffer, and SASS to develop your Drupal application. These are tools used to produce your site, but not your site. Therefore, these tools 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.