How to choose a Git workflow

Before you open-source your software, you need to select a contribution workflow and follow recommended community standards to communicate your workflow with a:

• README: Your repository's "home page" with instructions for how to consume your product.
• CONTRIBUTING guide: Instructions for how to contribute to your product.
• CODE_OF_CONDUCT: A cultural declaration of team norms and behaviors.
• LICENSE: A legal declaration.

These documents are essential for building a strong community of consumers and contributors.

Since Git manages change with branches and Pull Requests, Git workflows are basically process models for reviewing, discussing, approving, and merging branches. Git users therefore refer to their change control processes as branching models. For open source products that use Git, the branching model is the change control model.

Selecting a Git collaboration workflow depends on the complexity of your product. Here are the most popular (and well-documented) workflows.

Feature-branch-workflow

The Feature-branch-workflow is good for simple to moderately complex products. Products like libraries, modules, and even some micro-services benefit from the feature-branch-workflow's simplicity. Even [technically sophisticated software products][eslint-developer-guide-url] use the feature-branch-workflow as long as they're loosely-coupled and well-documented.

Gitflow

Gitflow builds on the feature-branch-workflow by adding develop and release branches, which allows teams to: * Add net-new features by branching from develop * Address emergency defects by branching from master * Manage releases without affecting development. Gitflow works well for large products (i.e, "monolithic applications"), but it's harder to manage.

Forking Workflow

The forking workflow focus on where contributors pull and work on your product's source code. Instead of pulling from and pushing to a single, "central" repository, the forking workflow creates a copy of the original repository and hosts that copy under another user account, organization, or project. This allows contributors to create topic branches and submit pull requests to their own repository instead of your yours.

Forking workflows still use either a feature-branch-workflow or Gitflow; the difference has to do with "who" hosts the repository.