There is what we call feature branch in git. Imagine for example I am making a game and I need to add a Power-up feature.

How I see my commits names with feature branches:
Branch name: Adding Power-up.
First commit name: Added prefab.
Second commit name: Implemented graphics.
Third commit name: Added collision detection.
Fourth commit name: Added effect on player on collision.

How I see my commits names without features branches:
First commit name: Adding power-up: added prefab.
Second commit name: Adding power-up: added graphics.
Third commit name: Adding power-up: added collision detection.
Fourth commit name: Adding power-up: added effect on player on collision.

When commit were files, I would make a directory called Power-up and put prefab, graphics, collision detection, effect on player on collision inside that folder.

Another usage of git branches is to separate dev version from production version.

  1. If my intuition is correct, are git feature branches comparable to folders on explorer, and git master and dev branch comparable to environments?
  2. Have I miss another "type" of branch?
  3. If there is distinct types of branches, should git add some structuring? (like a command called git featureBranch <newBranchName> or git environmentBranch <newBranchName> maybe)

- https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
- https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

1 Answer 1


Not to get all philosophical, but a branch in git is an alternate reality of your code base — a parallel universe — in which a new feature or defect fix is developed in isolation from all other code changes.

A branch in git should not be viewed as a "folder" containing files. It should be viewed as a timeline recording independent and isolated changes to your code base.

The master branch is the one common timeline upon which all others are based. All other parallel universes (branches) splinter from master and evolve in their own way (commits to the other branches). When the new feature or bug fix is ready to be included in the other timelines (other branches) these alternate realities collide in the form of a git merge.

Some branches live longer than others. A defect fix might only be around for a few days. A new feature branch might be around for a few weeks. The "dev" branch might be cleaved from master at the beginning of the project, and lives until the application is retired.

Branches can be differentiated from each other based on their intended use and life span, which gives you something akin to "branch types:"

  • master: Created on day 1. Lives until the repository is deleted. Usually is the canonical source that all other branches are ultimately based on.
  • An integration branch: Work from many people is integrated here so it can be properly tested before being merged into master. Can be called things like "dev" or "development" or could be named after application environments (like "qa" or "uat")
  • Defect fix: A short lived branch to fix a production issue
  • New feature: A branch, usually fairly short lived, to add new functionality to the system

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.