Skip to content

Latest commit

 

History

History
172 lines (140 loc) · 4.35 KB

File metadata and controls

172 lines (140 loc) · 4.35 KB

Git Flows

Git workflows for branching, tagging, and releasing vary depending on team structure, project complexity, and deployment strategy. Here are some commonly used workflows:


1. Branching Workflows

Branching strategies define how teams collaborate, handle feature development, and release management.

a) Git Flow (Best for structured release cycles)

A well-defined model for large teams and projects with planned releases.

graph TD;
    A[main] -->|create| B[develop]
    B -->|create| C[feature/branch-name]
    C -->|merge| B
    B -->|create| D[release/x.y.z]
    D -->|merge| A
    D -->|merge| B
    A -->|create| E[hotfix/x.y.z]
    E -->|merge| A
    E -->|merge| B
Loading
  • Main branches:

    • main (or master): Always contains stable production-ready code.
    • develop: Integration branch for features before a release.
  • Supporting branches:

    • Feature branches (feature/branch-name): Created from develop for new features, merged back when complete.
    • Release branches (release/x.y.z): Created from develop when preparing for a release, merged into main and develop after release.
    • Hotfix branches (hotfix/x.y.z): Created from main for urgent bug fixes, merged into main and develop.

Example:

git checkout -b feature/new-feature develop
# Work on feature
git checkout develop
git merge feature/new-feature
git branch -d feature/new-feature

b) GitHub Flow (Best for Continuous Deployment)

A simpler workflow suitable for fast-moving projects and small teams.

graph TD;
    A[main] -->|create| B[feature/branch-name]
    B -->|pull request| A
    A -->|merge| C[main]
    C -->|deploy| D[production]
Loading
  • Only one permanent branch (main)
  • All work happens in short-lived feature branches.
  • Merges are done via pull requests (PRs), often requiring approval before merging into main.

Example:

git checkout -b feature/new-feature main
# Work on feature
git push origin feature/new-feature
# Open a PR and merge after review

c) GitLab Flow (Best for CI/CD and DevOps)

A mix of GitHub Flow and Git Flow, with structured release branches.

graph TD;
    A[main] -->|create| B[feature/branch-name]
    B -->|merge request| A
    A -->|tag| C[release/x.y.z]
    C -->|deploy| D[production]
    A -->|create| E[environment/branch-name]
    E -->|merge request| A
Loading
  • main always contains production-ready code.
  • develop or environment branches (staging, qa) are optional.
  • Feature branches are merged into main (or develop).
  • Releases are tagged on main.

Example:

git checkout -b feature/new-feature main
# Work, then merge via MR (merge request)
git tag v1.0.0
git push origin v1.0.0

2. Tagging Workflows

Tags mark specific commits, often for releases.

Lightweight Tags (Just a reference to a commit)

git tag v1.0.0
git push origin v1.0.0

Annotated Tags (Stores metadata like message and author)

git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin v1.0.0

Deleting a Tag

git tag -d v1.0.0  # Local deletion
git push origin --delete v1.0.0  # Remote deletion

3. Release Workflows

a) Git Flow-Based Release Management

  • Create a release/x.y.z branch from develop.
  • Stabilize it (bug fixes, testing).
  • Merge into main and tag.
  • Merge back into develop (to keep fixes).

Example:

git checkout -b release/1.0.0 develop
# Fix bugs, then finalize release
git checkout main
git merge release/1.0.0
git tag v1.0.0
git push origin v1.0.0
git checkout develop
git merge release/1.0.0

b) GitHub Flow-Based Release

  • Merge features into main via PRs.
  • Tag the commit for the new release.

Example:

git tag v1.0.0
git push origin v1.0.0

c) Hotfix Release (Emergency Fix)

  • Create a hotfix/x.y.z branch from main.
  • Fix the issue and merge back into main and develop.
  • Tag the release.

Example:

git checkout -b hotfix/1.0.1 main
# Fix the issue
git checkout main
git merge hotfix/1.0.1
git tag v1.0.1
git checkout develop
git merge hotfix/1.0.1

Which Workflow Should You Use?

  • For large teams & structured releases → Git Flow.
  • For fast iteration & CI/CD → GitHub Flow.
  • For DevOps teams with multiple environments → GitLab Flow.