Git Branch Strategy for Beginners: Creating Feature Branches and Merging with Pull Requests

Why Use Feature Branches?

In a nutshell, they help you isolate work to merge safely.

• Main Branch: The "stable" version ready for deployment or sharing
• Feature Branch: A "workspace" for individual features or fixes
• PR (Pull Request): A "checkpoint" to review changes, resolve conflicts, and keep records, ensuring clarity and ease of rollback in case of errors.

Basic Branch Structure (Recommended for Beginners)

Branch Naming Conventions

While teams differ, beginners usually find these guidelines sufficient:

• main: The central branch
• feature/feature-name: For developing new features
• fix/bug-name: For fixing bugs Example: For adding a login button, use feature/login-button.

Simple Commit Message Rules

• Start with a verb: "Add…", "Fix…", "Update…"
• Keep it concise
• One change per commit Example: Add login button UI

Step-by-Step: From Creating a Feature Branch to Merging

Here’s a common scenario. (Examples use GitHub, but similar flows apply to GitLab.)

1) Start with the Latest Main

First, ensure your local main is up to date.

git checkout main
git pull origin main

2) Create and Switch to a Feature Branch

git checkout -b feature/login-button

Now, all changes will accumulate on this branch, leaving main untouched.

3) Modify Code and Check Status

For instance, let's say you added a button in index.html.

git status
git diff

• git status: Shows which files changed
• git diff: Details the changes

4) Stage and Commit Changes

git add index.html
git commit -m "Add login button UI"

If multiple files change, git add . is an option. However, beginners benefit from selecting add files precisely to avoid mistakes.

5) Push to Remote

If it's your first push, use the -u option.

git push -u origin feature/login-button

6) Create a Pull Request

On the remote repository, you’ll typically see a “Compare & pull request” button.

Include key details in your PR:

• What you did (summary)

• Why you did it (background/issue)

• How you tested it Example:

• Changes: Added login button UI

• Verification: Opened the page locally and confirmed button display

• Note: Click events to be added in the next PR

7) Reflect on Feedback and Merge

If feedback, like "change button class name," comes in, modify the branch, commit, and push. It updates automatically in the PR.

git add index.html
git commit -m "Update button class name"
git push

Once approved, click Merge on the PR screen to integrate into main. Teams often choose between:

• Merge Commit: Preserves commit history (safest option)
• Squash and Merge: Combines commits for clarity (often favored for beginners)

Common Issues and Solutions

1) "My Branch is Behind Main"

If main changes significantly during your work, incorporate its updates to reduce conflicts.

git checkout main
git pull origin main
git checkout feature/login-button
git merge main

Handle any conflicts and:

git add .
git commit -m "Resolve merge conflict"
git push

2) Worked on the Wrong Branch

It happens—commit your work, then switch branches. Regularly verify your branch with git branch to prevent errors.

git branch

3) PR is Too Large

Large PRs are hard to review. Break features down:

• UI PR
• Functionality PR
• Refactoring PR Teams appreciate when changes are broken into smaller chunks.

Key Takeaways for Beginners

1. Always keep main stable
2. Do all work in feature branches
3. Include “what/why/how” in PRs Mastering this flow eases collaboration significantly. Next steps might include adding PR templates, code review checklists, and CI tests to strengthen your development process.