Develop Branch in Git — what it is, purpose and working principles

What is Develop Branch in Git

Develop Branch (development branch) is a long-lived branch in Git Flow that serves as the central hub for code integration from all developers. Feature branches are merged into it after development completion and code review.

Code in develop is always in a state ready for creating a release, although not yet deployed to production. This means that all features in develop have passed review, testing, and integration checks, but are still awaiting their release cycle.

Unlike main, where each code version is a release, develop contains a continuous stream of changes. Commits in develop appear as feature branches are merged, which can happen several times a day.

According to Vincent Driessen, 2010, develop is a key element of a successful branching model, as it separates draft work from versions ready for release.

Differences between develop and main branch

Understanding the differences between develop and main is critical for proper Git Flow workflow. These branches serve different functions and have different stability requirements.

Splitting into develop and main allows the team to continuously integrate new code without risking production version stability. Developers can see their code in develop immediately after PR approval, even before the official release.

Role of develop in Git Flow

In the Git Flow model, develop occupies a central place between feature branches (source of changes) and release branches (preparation for release). Understanding this hierarchy is the foundation of effective branching.

• Feature → Develop — each completed feature is merged into develop via a Pull Request with code review.
• Develop → Release — when enough changes have accumulated for a release, a release branch is created from develop.
• Release → Main + Develop — after final preparation, the release branch is merged into main (release) and back into develop (bug fixes).
• Hotfix → Main + Develop — critical fixes are created from main and merged into both branches.

This structure ensures that develop always contains the latest code with all new features, while main contains only verified production code. This is especially important for mobile projects with long review cycles in App Store and Google Play.

Develop’s relationship with other Git Flow branches

Develop serves as the central link between feature, release, and hotfix branches. Understanding merge directions is essential for preventing conflicts and commit loss.

Code quality requirements in develop

Code quality in develop must be high, but not absolute. Unlike main, where every error means an urgent hotfix, develop allows minor imperfections that will be fixed before release.

Minimum requirements for code before merging into develop:

• Compilation — code must compile without errors. A broken build in develop blocks the entire team’s work.
• Unit tests — all existing tests must pass. New code must be covered by tests at least 70%.
• Code style — code must conform to the team’s accepted formatting and naming standards.
• No deprecated API — use of deprecated methods is not allowed in new code.

Automated checks in the CI/CD pipeline should run on every push to develop. If the build breaks, the responsible developer must fix the issue within an hour or revert their commit.

CI/CD checks for develop

Setting up GitHub Actions for develop ensures that every PR goes through automated checks before merging. A typical pipeline includes build, tests, and linting.

# GitHub Actions — checking develop after merge
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

Merge rules for develop

Merging into develop must follow strict rules to maintain the stability of the integration branch. Violating these rules leads to conflicts, broken builds, and wasted team time.

• Only via Pull Request — direct push to develop is prohibited. All changes go through code review.
• Minimum one approve — PR must be approved by at least one developer not involved in the task.
• Squash merge — it is recommended to combine all feature branch commits into one when merging into develop for a clean history.
• PR must be up-to-date — before merging, PR must be updated relative to the latest develop commit (rebase or merge).

The PR up-to-date rule is especially important. If a feature branch was created a week ago and develop has moved 50 commits ahead, direct merging could lead to conflicts that are better resolved in the context of the PR rather than in develop.

Protecting develop from incorrect merges

Branch protection rules are settings at the GitHub, GitLab, or Bitbucket level that prevent incorrect changes to develop. They ensure that even an accidental push won’t break the integration branch.

Recommended protection rules for develop:

• Require pull request — prohibit direct push to develop. All changes only via PR.
• Require approvals — minimum 1-2 approvals before merging PR.
• Require status checks — block merging if CI/CD pipeline has not passed.
• Require up-to-date — PR branch must be updated relative to develop before merging.
• Restrict push access — limit push rights to develop only for senior developers.

Setting up develop protection takes 10 minutes but prevents weeks of downtime related to a broken integration branch. For mobile projects with multi-platform teams, this is especially relevant.

Example commands for working with develop

Let’s consider a typical developer’s day: in the morning they update develop, create a new feature branch, and after completing the task merge changes back into develop.

# Morning develop sync
git checkout develop
git pull origin develop

# Creating a new feature branch from develop
git checkout -b feature/add-push-notifications

# Working on the feature...
git add . && git commit -m "Add FCM integration"

# Updating develop during development
git fetch origin develop
git rebase origin/develop

# After PR approval — update local develop
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

The git pull command in develop performs two operations at once: git fetch (retrieves new commits from the server) and git merge (merges them with the local branch). For develop, this is the standard synchronization method.

Recovering develop after a broken merge

If code that broke the build gets into develop, you need to act quickly. Every hour of develop downtime is blocked work for the entire development team.

If code that broke the build gets into develop, use git revert to create a new commit that undoes the problematic changes. Do not use git reset in develop — it rewrites history that other team members already have.

# Finding the problematic commit
git log --oneline develop

# Reverting a commit via revert (safe)
git revert a1b2c3d

# Pushing the fix to remote develop
git push origin develop

# Viewing changes in a specific commit
git show a1b2c3d --stat