Mastering Git Workflow: Branching, Pull Requests, and Conflict Resolution

Git Workflow Overview

A structured Git workflow is essential for large, multi‑developer projects. The model described uses three branch types— master , release and feature —and a pull‑request (PR) based code‑review process.

Branch Types

Master Branch

Always mirrors the production environment.

No direct commits are allowed; all development occurs on other branches.

Only after a release branch is merged back into master is the production code updated.

Release Branch

Created at the start of a project from master.

All code for a specific product lives in a branch named release/… (e.g., release/fb for a Facebook‑like app).

Parallel projects share the same repository but use independent release branches such as release/messenger to avoid cross‑project conflicts.

Feature Branch

Each new feature is developed in its own branch prefixed with feature/.

Feature branches are typically created from the corresponding release branch.

Examples: feature/login – Facebook login page. feature/friendrequest – Add‑friend page. feature/newsfeed – News‑feed page.

Pull Request Process

A pull request is a request to merge one branch into another; it is not the same as git pull. Developers push changes to a feature branch, then open a PR targeting the appropriate release branch. The technical lead reviews the changes before merging.

Open a PR with feature/login as the compare branch and release/fb as the base branch.

Provide a concise title and description.

Assign a reviewer (typically the technical lead).

After approval, merge the feature branch into the release branch.

Handling Merge Conflicts

If a conflict arises (e.g., when two feature branches modify the same code), there are two common resolutions:

The PR reviewer resolves the conflicts during the review.

The developer updates their feature branch with the latest release branch ( git merge release/fb or git pull) and resolves conflicts locally before reopening the PR.

Final Integration

When a release is ready, merge the release branch back into master and deploy to production. This keeps master in sync with the production‑ready code for future projects.

Illustrative Diagrams

Reference

Original article: https://medium.freecodecamp.org/how-to-use-git-efficiently-54320a236369