Why Use Git Workflows? Master Trunk-Based, GitFlow, Feature & Forking Strategies

What is a Workflow? Why Use It?

Today we explain what a workflow is and why you should adopt one. A workflow defines how you and your team collaborate with Git and GitHub. Choosing the right workflow depends on team structure, project complexity, and your release strategy. Below are the most common workflows and their use cases.

Trunk‑Based Development

This is the most widely used workflow; you may already be using it without knowing its name. Developers work directly on the main branch or create short‑lived feature branches, merging changes to main multiple times a day. Frequent integration minimizes merge conflicts and enables fast delivery, real‑time collaboration, and fewer conflicts.

Workflow Steps

Start work: <code>git checkout -b feature-article</code>

Make changes and push frequently: <code>git commit -m "Finish Article"</code>

Merge branch: <code>git checkout main git merge feature-article git push origin main</code>

GitFlow

Unlike a single main branch, GitFlow maintains two primary branches: main (production) and dev (integration). From dev you create other branches:

Feature branches : created from dev and merged back after completion.

Release branches : created from dev when preparing a release.

Hotfix branches : created from main to fix urgent issues, then merged into both main and dev .

main always stores production code, while dev integrates all feature branches. Development occurs on dev to avoid working directly on production code. GitFlow is ideal for CI/CD.

Workflow Steps

Initialize GitFlow: <code>git flow init</code> During initialization you answer prompts such as which branches to use for production ( main ) and next‑release integration ( dev ), and the prefixes for feature, bugfix, release, hotfix, etc.

Start a new feature: <code>git flow feature start feature-article</code>

Finish the feature: <code>git flow feature finish feature-article</code> This merges the feature into dev , deletes the feature branch, and switches back to dev .

Publish the feature (optional): <code>git flow feature publish feature-article</code>

Create a release branch: <code>git flow release start v1.0</code>

Finish and deploy the release: <code>git flow release finish 'v1.0'</code> The command merges the release into main , tags the release, back‑merges the tag into dev , deletes the release branch, and leaves you on dev . Sample output includes branch switches, merge summaries, and tag creation.

Feature Branch Workflow

This workflow suits teams developing multiple features simultaneously. Each feature lives in its own branch and is merged into main after review.

Workflow Steps

Create a feature branch: <code>git checkout -b feature-article</code>

Work and commit changes: <code>git add . git commit -m "Added Feature Branch Topic"</code>

Push the branch and open a Pull Request: <code>git push origin feature-article</code>

After review, merge the changes into the remote and local main branch.

Forking Workflow

Developers fork a repository (instead of working directly on the original), clone their fork, create branches, push changes to their fork, and submit a Pull Request to the original repository. This is common in open‑source projects.

Workflow Steps

Fork the repository on GitHub.

Clone the forked repository: <code>git clone https://github.com/lorenzouriel/ebook-git-github.git</code>

Create a branch and make changes: <code>git checkout -b feature-article git add . git commit -m "Added feature article" git push origin feature-article</code>

Submit a Pull Request to the original repository.