- Git - Home
- Git - Version Control
- Git - Basic Concepts
- Git - Command Line
- Git - Installation
- Git - First Time Setup
- Git - Basic Commands
- Git - Getting Help
- Git - Tools
- Git - Cheat Sheet
- Git - Terminology
- Git - Life Cycle
- Git - Get a Repository
- Git - Adding New Files
- Git - Recording Changes
- Git - Viewing Commit History
- Git Branching
- Git - Branches in a Nutshell
- Git - Creating a New Branch
- Git - Switching Branches
- Git - Branching and Merging
- Git - Merge Conflicts
- Git - Managing Branches
- Git - Branching Workflows
- Git - Remote Branches
- Git - Tracking Branches
- Git - Rebasing
- Git - Rebase vs. Merge
- Git - Squash Commits
- Git Operations
- Git - Clone Operation
- Git - Tagging Operation
- Git - Aliases Operation
- Git - Commit Operation
- Git - Stash Operation
- Git - Move Operation
- Git - Rename Operation
- Git - Push Operation
- Git - Pull Operation
- Git - Fork Operation
- Git - Patch Operation
- Git - Diff Operation
- Git - Status Operation
- Git - Log Operation
- Git - Head Operation
- Git - Origin Master
- Git Undoing
- Git - Undoing Changes
- Git - Checkout
- Git - Revert
- Git - Reset
- Git - Restore Operation
- Git - Rm
- Git - Switch Operation
- Git - Cherry-pick
- Git - Amend
- Git on the Server
- Git - Local Protocol
- Git - Smart HTTP Protocol
- Git - Dumb HTTP Protocol
- Git - The SSH Protocol
- Git - The Git Protocol
- Git - Getting Git on a Server
- Git - Setting up the Server
- Git - Daemon
- Git - GitWeb
- Git - GitLab
- Git - Third Party Hosted Options
- Distributed Git
- Git - Distributed Workflows
- Git - Contributing to a Project
- Git - Maintaining a Project
- Customizing Git
- Git - Configuration
- Git - Hooks
- Git - Attributes
- Git - Init
- Git - Commit
Git - Branching Workflows
Depending on how they're used, you can divide branches into two major groups.
Long-Running Branches
Short-Lived / Topic Branches
Note: This is just a semantic division. Technically (and practically), a branch is just a branch and always works in the same way.
Long-Running Branches
The three-way merge feature in Git makes branch merging easier over time. These branches are used on a higher level, independent of a single feature or bugfix development.
Multiple long-lived branches for various phases of development are frequently maintained by developers. This comprises:
A master branch containing code that is reliable and ready for release to production.
A develop or next branch which integrates reliable features from temporary branches into continuing testing and development.
These branches typically represent states in your project lifecycler and can remain in your project for a longer time (or even all the time).
The Workflow includes:
Developing features on short-lived topic branches (e.g., auth-module).
Merging tested and stable branches into the next or develop branch.
Branches function as stable silos in a hierarchical structure.
After passing tests, commits progress from less stable branches to more stable ones.
Some projects integrate less reliable features using additional branches such as proposed updates(pu).
Large or complicated projects benefit from managing numerous long-running branches because it preserves stability and controls feature integration.
Topic Branches
Every time you start working on a new feature or bugfix, you should create a new branch for this topic. Such branches are useful for projects of any size since they act as temporary units for particular tasks or features.
Git's efficiency enables for the frequent creation, modification, merging, and deletion of branches during the development process, in contrast to traditional version control systems.
Branches allow for distinct growth without affecting with the main source by isolating work.
Git's efficient branching model enables quick branch operations, reduces overhead, and integrates seamlessly with various development workflows like GitHub Flow and Gitflow.
Branches used in earlier discussions, such as auth-module and bugfix, were deleted after merging into the main branch.
This method divides the work into topic-specific branches and enables quick context change.
It makes it simpler to review changes and improves understanding of how they affect the codebase.
Following diagram explains this:
After starting on the master branch, developers branch off to work on specific tasks (like task A).
They might make branches similar to taskA-v2 to test out different approaches.
It is typical to go back to the master branch and complete more work there.
Additionally, developers make experimental branches like exploratory.
This process generates a commit history that describes the history and purpose of every branch in detail.
The above diagram illustrates the branching process, and some following points are observed as below:
taskA-v2 is found to be the best option after evaluation, and exploratory turns out to be surprisingly beneficial based on feedback from colleagues.
It is safe to abandon the original taskA branch along with commits C5 and C6.
Exploratory and taskA-v2 can be easily integrated into the main branch.
This flexible strategy guarantees efficient handling of modifications, irrespective of their temporal sequence.