Git — Workflows

Terminal

Published

July 10, 2026

Modified

July 10, 2026

Git workflows are conventions for how a team uses Git to develop software. They define how branches are created, when code is merged, and how releases are managed. The “best” workflow depends on your team size, release frequency, and project complexity.

Centralized

This is the simplest workflow and resembles traditional version control systems.

main
 |
 +-- Commit
 |
 +-- Commit
 |
 +-- Commit

Everyone commits directly to a single “main” branch. Very easy to learn, no branching, good for solo projects and Git beginners. Collaboration with others on small projects will increase merge conflicts.

Feature Branch

Branch-based workflows¹ are widely used. Every new feature or bug fix gets its own branch.

Branch — Create a dedicated branch to keeps work isolated from main.
Commit — Small, logical commits… represent a complete, reversible change.
Push — Share your branch with the remote for backup and visibility.
Review — Open a merge request. Collaborators leave feedback.
Integrate — Once approved, merge or rebase into the main branch.
Clean up — Delete merged branches locally and remotely.

# create and switch to a new branch
git checkout -b $branch

# stage and commit changes
git add $files
git commit -m 'describe the change'

# push branch to remote
git push -u origin $branch

Open a pull request or merge request through the platform’s web interface. The review, approval, and merge steps happen there — no command-line interaction needed.

Rebase

If you have an open merge request (MR) from your branch into main, rebasing your branch onto the updated main is a common way to keep the MR current. In a personal feature branch rebasing is usually fine because you own the branch history. When you rebase, Git rewrites the commits on your branch, but nobody else is depending on those exact commit IDs.

git fetch origin          # in the main branch
git checkout your-branch
git rebase origin/main

A normal push fails because Git sees that the histories are different.

git push --force-with-lease origin your-branch

Existing MR should update automatically because it points to the same branch. The diff will be recalculated against the newer main.

Many teams use this workflow because the MR stays clean:

No unnecessary merge commits
Conflicts are handled by the author
Reviewers see a focused change set
The final history is easier to read

Merge

If you want to avoid rewriting history:

git checkout your-branch
git fetch origin
git merge origin/main
git push origin your-branch

This creates a merge commit but does not require a force push.

Footnotes

GitHub flow, GitHub Docs
https://docs.github.com/en/get-started/using-github/github-flow ↩︎

--- title: 'Git — Workflows' categories: - Terminal date: 2026/07/10 date-modified: 2026/07/10 --- Git workflows are conventions for how a team uses Git to develop software. They define how branches are created, when code is merged, and how releases are managed. The "best" workflow depends on your team size, release frequency, and project complexity. # Centralized This is the simplest workflow and resembles traditional version control systems. ```txt main | +-- Commit | +-- Commit | +-- Commit ``` Everyone commits directly to a single "main" branch. Very easy to learn, no branching, good for solo projects and Git beginners. Collaboration with others on small projects will increase merge conflicts. # Feature Branch **Branch-based workflows**[^kl2Wq] are widely used. Every new feature or bug fix gets its own branch. [^kl2Wq]: GitHub flow, GitHub Docs <https://docs.github.com/en/get-started/using-github/github-flow> 1. **Branch** — Create a dedicated branch to keeps work isolated from main. 2. **Commit** — Small, logical commits… represent a complete, reversible change. 3. **Push** — Share your branch with the remote for backup and visibility. 4. **Review** — Open a **merge request**. Collaborators leave feedback. 5. **Integrate** — Once approved, merge or rebase into the main branch. 6. **Clean up** — Delete merged branches locally and remotely. ```bash # create and switch to a new branch git checkout -b $branch # stage and commit changes git add $files git commit -m 'describe the change' # push branch to remote git push -u origin $branch ``` Open a **pull request** or **merge request** through the platform's web interface. The review, approval, and merge steps happen there — no command-line interaction needed. ### Rebase If you have an open merge request (MR) from your branch into main, rebasing your branch onto the updated main is a **common way to keep the MR current**. In a **personal feature branch** rebasing is usually fine because you own the branch history. When you rebase, Git rewrites the commits on your branch, but nobody else is depending on those exact commit IDs. ```bash git fetch origin # in the main branch git checkout your-branch git rebase origin/main ``` A normal push fails because Git sees that the histories are different. ```bash git push --force-with-lease origin your-branch ``` Existing **MR should update automatically** because it points to the same branch. The diff will be recalculated against the newer main. Many teams use this workflow because the MR stays clean: * No unnecessary merge commits * Conflicts are handled by the author * Reviewers see a focused change set * The final history is easier to read ### Merge If you want to avoid rewriting history: ```bash git checkout your-branch git fetch origin git merge origin/main git push origin your-branch ``` This creates a merge commit but does not require a force push.