Mastering Git Workflow: A Simple Guide for Multi‑Developer Projects
This guide explains a straightforward Git workflow for multi‑developer teams, covering master, release, and feature branches, pull‑request reviews, handling merge conflicts, and merging back to master, illustrated with clear examples and images.
Git Workflow
When a project involves multiple developers, a proper Git workflow is essential.
This article presents a simple and effective workflow.
Scenario
Assume a project to develop the next generation of Facebook, with you as the technical leader and three developers: Alice (1 year experience), Bob (1 year experience), John (3 years experience).
Git Development Process
Master branch
The master branch always contains the production code.
No one, including the technical leader, may modify the master branch directly.
All development occurs on other branches.
Release branch
At project start, create a release branch from master.
The release branch holds all project code and is named with the prefix release/ , e.g., release/fb or release/messenger for different projects.
Using release branches isolates multiple projects from each other.
Feature branch
For each feature, create a feature branch prefixed with feature/ , e.g., feature/login , feature/friendrequest , feature/newsfeed .
Feature branches are created from the release branch.
Developers work on their own feature branches.
When a feature is ready, submit a pull request to merge it into the appropriate release branch.
Pull request
Do not confuse a pull request with git pull. Developers cannot push directly to the release branch; the technical leader reviews the code via a pull request before merging.
Example GitHub workflow:
compare is the developer’s feature branch (e.g., feature/login ).
base is the project’s release branch (e.g., release/fb ).
The developer adds a title and description, assigns a reviewer, and after approval merges the feature into the release branch.
Code conflicts
If two feature branches modify the same code, a conflict occurs when merging into the release branch.
The reviewer can resolve the conflict, or the developer can pull the latest release branch into their feature branch using git pull or git merge and resolve it locally.
Returning to master
After the project is completed, the release branch is merged back into the master branch.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Java High-Performance Architecture
Sharing Java development articles and resources, including SSM architecture and the Spring ecosystem (Spring Boot, Spring Cloud, MyBatis, Dubbo, Docker), Zookeeper, Redis, architecture design, microservices, message queues, Git, etc.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
