Beginner's Guide to Git Branching: Simplified Workflow with main, dev, and feature Branches

When you first dive into team projects, Git transforms from a version control system into a powerful teamwork tool. Suddenly, unintentional overwrites and broken features can disrupt the workflow. In this guide, we present a straightforward three-branch strategy (main, dev, and feature) that beginners can implement effortlessly, with a focus on collaboration through Pull Requests (PR). Forget complex rules; let's build safe and predictable work habits.

Limiting Branch Roles to Three

main: The “Always Deployable” Baseline

• Principle: main should never break.
• Avoid direct commits; use PRs only to update it.
• A stable main, even for small teams, brings peace of mind.

dev: The Integration Space for the Next Release

• dev is where integration testing happens.
• Develop features in feature branches, then merge into dev.

feature/*: Function-Specific Workspaces

• Create branches for each new feature or bug fix.
• Example naming:
• feature/login
• feature/profile-edit
• feature/fix-navbar

Easiest Collaboration Workflow (Step-by-step)

1) Create a Feature Branch from the Latest dev

git checkout dev
git pull origin dev
git checkout -b feature/login

• Starting with the latest dev reduces conflicts.

2) Work and Make “Small” Commits

git add .
git commit -m "Add login form UI"
git commit -m "Implement login API integration"

• Splitting commits into small, meaningful pieces makes reviews easier.
• Write messages that clearly show “what was done.”

3) Push and Open a PR (feature → dev)

git push -u origin feature/login

Include these three key points in your PR:

• Summary of changes: What did you implement/fix?
• Testing method: How did you verify the changes? (e.g., successful/failed login tests)
• Screenshots/Logs: Especially helpful for UI changes or error fixes.

4) Reflect on Reviews and Merge into dev

• Reviews are a process to align on team quality, not criticisms.
• After adjustments, push your changes to update the same PR automatically.

5) PR from dev to main at Deployment Time

• Once features stabilize in dev, open a PR to merge into main.
• Consider this PR as your “deployment bundle.”

Common Challenges and Solutions for Small/Beginner Teams

Fear of Conflicts

• Dragging out feature branches increases conflict risks. Keep features small and submit PRs often.
• To incorporate changes from dev:

git checkout feature/login
git fetch origin
git rebase origin/dev

• If rebasing feels tricky, starting with merge is fine; the key is to sync often.

“Urgent Fixes” - Where to Apply Them?

• For emergency fixes needed on main, teams may use hotfix/*. However, beginners are better off initially focusing on using feature/fix-... to merge into dev, then quickly deploy to main.

What to Look for in a PR Review?

Beginner Review Checklist (Minimal Version):

• Functionality: Does it perform as expected?
• Safety: Are exceptions handled, and errors messaged?
• Readability: Do variable/function names convey purpose?
• Scope: Are changes limited to relevant files?

Example Scenario: Team Building a Login Feature

1. A creates feature/login-ui for the interface and submits a PR to dev.
2. B works on feature/login-api for the API integration and submits a PR to dev.
3. The team tests together in dev (success/failure/token expiration).
4. If everything checks out, a PR is opened from dev to main for deployment. This approach's advantage is clear. It provides visibility into who is working on what and creates a safeguard for main against issues. Ultimately, it fosters a team's stability, which matters even more than development speed.

Conclusion: Simplicity in Rules Breeds Longevity

For beginners, the best Git strategy isn't the fanciest one but one that the team can follow daily. Keep main stable, use dev as an integration space, work in feature branches, and handle all changes through PR conversations. Adhering to these four principles significantly reduces collaboration stress.