Choosing a Strategy

Git is a tool, not a workflow. It allows you to create branches, merge them, and rewrite history, but it doesn’t tell you how your team should use these features. A “Workflow” is a set of rules your team agrees upon.

1. Gitflow

Popularized by Vincent Driessen in 2010, Gitflow is a strict branching model designed for project releases.

Structure

• Main: Stores the official release history.
• Develop: Integration branch for features.
• Feature: Branched from Develop. Merged back to Develop.
• Release: Branched from Develop. Merged to Main and Develop.
• Hotfix: Branched from Main. Merged to Main and Develop.

left to right direction
skinparam componentStyle rectangle

package "Gitflow" {
component "Main" as Main
component "Develop" as Develop
component "Feature" as Feature
component "Hotfix" as Hotfix
component "Release" as Release
}

Main --> Hotfix
Hotfix --> Main
Hotfix --> Develop

Main --> Develop
Develop --> Feature
Feature --> Develop
Develop --> Release
Release --> Main

Pros: robust, well-defined for packaged software. Cons: complex, slows down continuous delivery.

2. GitHub Flow (Feature Branch Workflow)

A simpler workflow used by GitHub and many modern web teams.

Rules

1. Anything in the main branch is deployable.
2. To work on something new, create a descriptively named branch off main.
3. Commit to that branch locally and push to the server.
4. Open a Pull Request (PR) for help or review.
5. Merge into main after approval.
6. Deploy immediately.

Pros: simple, supports CD (Continuous Deployment). Cons: may be too simple for complex release cycles with versioned artifacts.

3. Trunk-Based Development

The gold standard for high-performing DevOps teams (like Google, Facebook).

Rules

• Developers collaborate on a single branch (Trunk/Main).
• Branches are short-lived (hours, not days).
• Developers merge to main at least once a day.
• Feature Flags (toggles) are used to hide incomplete features in production, rather than long-running feature branches.

Pros: no “merge hell”, instant feedback, enables true CI. Cons: requires high discipline and strong automated testing.

Pull Requests (Merge Requests)

Regardless of the branching model, the mechanism for code review is the Pull Request (PR).

A PR is a request to merge your branch into a target branch. It provides a UI for:

• Discussing code line-by-line.
• Running automated checks (CI).
• Requiring approvals.

Best Practices for PRs

1. Keep it small: < 400 lines of code. Large PRs don’t get reviewed properly.
2. Context: Explain why you made the change.
3. Self-Review: Review your own code before asking others.

# Simulate starting a feature
git init
git checkout -b feature/login-page
echo "code" > login.js
git add login.js
git commit -m "Implement login"

# Simulate merge request acceptance
git checkout main
git merge --no-ff feature/login-page

... Merge made by the 'ort' strategy.

# Create a new branch named 'feat/ui' and switch to it.
git switch -c feat/ui

# Create a new branch named 'feat/ui' and switch to it.
git switch  feat/ui