Feature Branch in Git: What It Is, How to Create and Work with Branches

What Is a Feature Branch in Git

Feature Branch is a temporary Git branch created from develop to work on a specific functionality. Unlike the long-lived main and develop branches, feature branches exist for a limited time — from a few hours to a few weeks.

The main purpose of a feature branch is to isolate changes related to one task from the rest of the codebase. A developer can experiment, make many commits, and even break code in their own branch without affecting other team members.

After development is complete, the feature branch is merged back into develop via a Pull Request with mandatory code review. After merging, the branch is typically deleted to keep the repository clean.

According to Vincent Driessen, 2010, the Git Flow model with feature branches became an industry standard thanks to its clear separation of responsibilities between different branch types.

Feature Branch Workflow

The workflow with feature branches consists of a sequence of steps that a developer performs for each new feature. This process minimizes merge conflicts and ensures code quality control.

1. Create a branch from the latest commit on develop. The developer switches to develop, updates it, and creates a new feature branch.
2. Development and commits in the feature branch. The developer makes changes, commits with clear descriptions, and periodically pushes the branch to the remote repository.
3. Synchronize with develop — during development, the main branch may move forward. The developer performs a rebase or merge of develop into their feature branch.
4. Create a Pull Request — when the feature is ready, the developer opens a PR for code review. The team reviews the code and leaves comments.
5. Merge and delete — after PR approval, the branch is merged into develop and deleted both locally and remotely.

Periodic synchronization with develop is critically important. The longer a feature branch lives without merging changes from develop, the higher the likelihood of conflicts during the final merge.

Feature Branch Sync Frequency

Feature Branch Naming Conventions

Branch naming is an important part of team discipline. A consistent naming standard allows everyone to quickly identify which task is being worked on and who is doing it.

• feature/name — the feature/ prefix is used in classic Git Flow. Example: feature/added-auth-module.
• feature/JIRA-123-description — linking to a task ID in a tracking system. Example: feature/PROJ-42-add-login.
• feature/type/name — extended format with task type. Example: feature/feat/analytics-dashboard.

Using a task ID from JIRA, Trello, or another system is a best practice. It automatically links code to the task and simplifies branch search via git log.

Pull Request Process

Pull Request (or Merge Request in GitLab) is a request to merge a feature branch into develop. A PR is not just a technical operation, but a team code review process that improves code quality and spreads knowledge within the team.

A good PR contains a title with a brief task description, a link to the ticket, and a description of changes. The developer should state what was done, which files were changed, and whether there are potential risks for other parts of the project.

The team reviews the code in the PR, leaves comments, requests changes, and approves the merge. After approval, a merge or squash merge is performed.

The average PR review time in mobile development ranges from 4 to 24 hours. The Danger library automates some checks by running linters and tests directly in the PR.

Tips for Creating a Good PR

• Size — no more than 300-400 lines of changes. Large PRs are hard to review, and review quality drops.
• One PR — one task — avoid mixing unrelated changes in a single request.
• Screenshots — for UI changes, attach before and after screenshots.
• Tests — write unit tests for new functionality and include them in the PR.

Feature Branch Merge Strategies

After PR approval, the feature branch can be merged into develop in various ways. The choice of merge strategy affects the commit history and the ability to roll back changes.

• Merge commit — creates a merge commit, preserving the entire commit history of the feature branch. History remains complete, but the branching graph becomes more complex.
• Squash merge — combines all commits from the feature branch into one and adds it on top of develop. History becomes cleaner, but information about intermediate commits is lost.
• Rebase and merge — rewrites feature branch commits on top of the latest develop commit and merges without an additional commit. History remains linear.

For mobile projects with frequent releases, squash merge is most commonly used: it provides a clean history in develop, while development details remain in the PR description and the tracker task.

Common Mistakes When Working with Feature Branches

Even experienced developers make mistakes when working with feature branches. Knowing common problems helps avoid wasted time and data loss.

• Branch lives too long — a feature branch lives longer than 2-3 weeks without synchronization with develop, leading to massive merge conflicts.
• Commits with unclear descriptions — messages like “fix” or “update” do not explain what was changed and why.
• Mixing tasks — two unrelated features are developed in the same feature branch, making selective rollback impossible.
• Lack of synchronization — the developer does not run git fetch and does not update develop, causing conflicts during the final merge.

The best way to avoid these issues is to agree on work rules at the start of the project and use automated checks in the CI/CD pipeline.

Command Examples for Working with Feature Branches

Let’s consider a practical scenario: a developer starts a new authentication feature for a mobile app. They create a feature branch, work on the code, and complete the task with a Pull Request.

# Update develop and create feature branch
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Working on the feature: commits
git add src/ui/login/
git commit -m "Add login screen layout"

# Push feature branch to remote
git push origin feature/add-login-screen

# Synchronize with develop (rebase)
git fetch origin develop
git rebase origin/develop

# After PR approval: update local develop and delete branch
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

The git branch -d command deletes a branch only after its changes have been fully merged. If the branch is not merged, Git will suggest using git branch -D for force deletion — use this flag with caution.

Automating Checks in a Feature Branch

A CI/CD pipeline should run for every feature branch before creating a PR. This helps detect issues early, before the code reaches other developers for review.

# GitHub Actions for checking feature branch
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

The pipeline verifies that the code compiles, tests pass, and code style meets team standards. Only after passing all checks can a Pull Request be created.