Master Git Workflows: From Centralized to Forking for Seamless Team Collaboration

Centralized Workflow

The simplest Git workflow where developers work directly on the local master branch, commit changes, and push to the remote master. It is suitable for small teams or projects with infrequent development, but can cause tangled commit history and merge conflicts when multiple features are developed in parallel.

Feature Branch Workflow

Developers create a new branch from master for each feature, work on that branch, and submit a pull request (PR) for code review before merging back to master. This isolates features, keeps history clean, and enables collaborative review.

$ git checkout -b feature/rate-limiting

$ git add limit.go
$ git commit -m "add rate limiting"

$ git push origin feature/rate-limiting

After review, the maintainer merges the PR using one of three methods:

Create a merge commit : preserves full history.

Squash and merge : combines all PR commits into a single commit.

Rebase and merge : replays commits onto master head (riskier for beginners).

For most projects, Create a merge commit is recommended.

Git Flow Workflow

Git Flow defines five branch types— master, develop, feature, release, and hotfix —assigning clear roles to each. It is well‑suited for large or fast‑moving projects.

Git Flow Branches

Git Flow Development Process (example)

Starting from version 0.9.0, a new feature print‑hello‑world is added, a hotfix is applied, and the workflow proceeds through develop, release, and master branches with appropriate merges and tags.

$ git checkout -b develop master

$ git checkout -b feature/print-hello-world develop

$ git commit -a -m "print 'hello world'"

$ git checkout -b release/1.0.0 develop
$ go build -v .
$ git checkout master
$ git merge --no-ff release/1.0.0
$ git tag -a v1.0.0 -m "add print hello world"

Forking Workflow

Common in open‑source projects, developers fork the upstream repository, work on their own copy, and submit a PR back to the original project. This isolates personal workspaces and improves security by avoiding direct write access to the upstream repository.

$ git clone https://github.com/colin404fork/gitflow-demo
$ cd gitflow-demo
$ git remote add upstream https://github.com/marmotedu/gitflow-demo
$ git fetch upstream
$ git checkout -b feature/add-function

After development, the feature branch is pushed, a PR is opened, reviewers comment, and the maintainer merges the changes.

Summary

Four Git workflows are covered:

Centralized: simple but prone to conflicts; best for tiny, low‑frequency projects.

Feature Branch: isolates work, adds code review; fits small to medium teams.

Git Flow: structured branching for large or fast‑iteration projects.

Forking: ideal for open‑source contributions, enhancing security and allowing many contributors.

Recommended usage: non‑open‑source projects → Git Flow; open‑source projects → Forking.