Module 4 Lesson 1: Branch basics and naming conventions

In older version control systems, branching was slow, difficult, and expensive. In Git, branching is incredibly fast and central to everything we do.

In this lesson, we explore what a branch actually is and how to organize them so your team (and your future self) stays sane.

---

1. What is a Branch?

To understand a branch, you first need to understand that Git doesn't store files; it stores commits.

A branch in Git is simply a lightweight, movable pointer to one of these commits.

• When you make a new commit, the pointer for your current branch automatically moves forward to that new commit.
• The main (or master) branch is just a pointer, no different from any other branch.

graph LR
    C1["Commit 1"] --> C2["Commit 2"]
    C2 --> C3["Commit 3"]
    Main["main"] --> C3
    HEAD["HEAD"] --> Main
    
    style Main fill:#f9f,stroke:#333,stroke-width:2px

---

2. Why Branch?

Imagine you are building a website and want to:

• Fix a spelling mistake on the Home page.
• Experiment with a new "Dark Mode" feature.
• Update the Privacy Policy.

If you do all of these in the main branch, your code becomes a mess of half-finished features. By using branches, you can keep the main branch stable and production-ready while you work on messy experiments in private branches.

---

3. Branch Naming Conventions

Consistency is key. Most professional teams use a prefix system:

• feature/: For new features (e.g., feature/login-screen).
• bugfix/: For fixing identified bugs (e.g., bugfix/fix-header-spacing).
• hotfix/: For urgent fixes in the production environment.
• refactor/: For cleaning up code without changing behavior.
• experimental/: For ideas that might never be merged.

Other Naming Best Practices:

• Kebab-case: Use hyphens (-) instead of spaces or underscores.
• Issue Numbers: Many teams include the Jira/GitHub issue number in the name (e.g., feature/102-responsive-footer).
• Be Descriptive: feature/auth is bad. feature/jwt-token-refresh is good.

---

4. The main Branch

The main branch should always represent the stable, working version of your code. You should rarely (if ever) commit directly to main once a project is live. Instead, you develop on branches and then "merge" them into main after they are tested and reviewed.

---

Lesson Exercise

Goal: Plan your branch structure.

1. Imagine you are building a simple "To-Do List" application.
2. You need to implement three things:
   • A "Delete Task" button.
   • A "Priority Levels" dropdown.
   • A fix for a bug where empty tasks are being saved.
3. Write down the names of the three branches you would create using the naming conventions learned in this lesson.

Observation: You'll see that simply by looking at the branch names, anyone on your team can immediately understand what work is being done.

---

Summary

In this lesson, we established:

• A branch is just a pointer to a commit.
• Branching allows for parallel, isolated development.
• Professional teams use naming prefixes like feature/ and bugfix/.
• The main branch should be kept stable at all times.

Next Lesson: We’ll learn the actual commands to create and switch between branches.