Git Branch Strategy for Beginners: Safely Add Features with Feature Branches and Pull Requests

Getting started with Git can be intimidating, not because of the commands, but because of the flow. Questions like "Where should I work?", "Is it okay to push this directly to main?", or "What if there's a conflict?" can cause anxiety. Today, we'll walk through the most practical and secure method to add and merge features using feature branches and pull requests, designed especially for beginners.

Why Do You Need a Branching Strategy?

A branching strategy serves as a safety net to prevent mistakes from spreading.

• Main (or master) should always be in a working state
• Feature additions are handled in feature branches
• Use PRs to review and merge changes By doing this, you can avoid "I committed directly to main in a rush and messed up" scenarios.

A Simple yet Powerful Structure: Main + Feature

For beginners, I recommend starting with the following simple structure:

• Main: Stable branch for deployment/sharing
• Feature/FeatureName: Branch for specific feature tasks (e.g., feature/login) As your team grows, you might add develop or release branches, but starting simple and expanding when needed is best.

Practically Adding a Feature: A Step-by-Step Guide

Step 1: Create a Branch from the Latest Main

git switch main
git pull origin main
git switch -c feature/login

The key is to make sure your main branch is up-to-date before creating a feature branch. This simple habit significantly reduces conflicts.

Step 2: Develop Only in the Feature Branch

For example, adding a login button:

git add .
git commit -m "feat: Added login button UI"

Keep commit messages clear and understandable. Recommended patterns: feat: ~, fix: ~, refactor: ~

Step 3: Push and Create a Pull Request

git push -u origin feature/login

Then, create a PR on your remote repository.

• Base: main

• Compare: feature/login In your PR description, include:

• What was done (summary of changes)

• Why it was done (background/reason)

• How to verify (testing method) Example:

• Changes: Added login button and click event

• Reason: Provide a login entry point

• Verification: Check button appearance and click event on login page

Step 4: Review Checklist for PRs (For Beginners)

Even if there’s no reviewer, use the PR as a chance to self-review.

• Are there unnecessary files (e.g., logs, temp files)?
• Are there unrelated changes?
• Is the commit too large for an easy review?
• Have you tested it locally at least once?

Step 5: Merge and Clean Up

Once approved, merge into main. Then, delete the feature branch.

git switch main
git pull origin main
git branch -d feature/login

The option to delete remote branches is usually available on the PR page. Cleaning up is crucial for maintaining trust in collaboration.

Common Issue 1: "What if There's a Conflict?"

Conflicts mean "both edited the same line differently," but it's not inherently bad. For beginners, the safest strategy is:

Incorporating Main Changes into Feature (Merge is Easier than Rebase)

git switch feature/login
git fetch origin
git merge origin/main

If conflicts arise, open the marked files and resolve them, then:

git add .
git commit

Tip: Start with merging rather than rebasing if there are no team-specific guidelines. It’s less confusing.

Common Issue 2: "I Committed Directly to Main..."

Don’t panic! If you haven't pushed yet, reverting is easy. However, the solution depends on specifics like push status and commit count. Knowing your exact situation ensures a safe recovery. Let me know the details, like “pushed or not” and “number of commits,” for tailored guidance.

Conclusion: Safety First in Development

In summary, remember this:

Create features in a feature branch, confirm with a PR, then merge into main.

Adopting this flow reduces errors when working solo and helps you adapt quickly in a team. Resist the urge to commit directly to main, and cultivate the habit of starting from a feature branch for a safer workflow.