Basic Rules and Naming Conventions for Managing Branches with Multiple People on GitHub

In the previous articles in this series, you've learned everything from the basics of using GitHub to how to contribute to collaborative development using `Fork` and `Pull Request`. You should no longer be afraid of developing on your own or contributing to open-source projects.

In this final installment of the series, we will focus on "branch management" to facilitate smooth team development. When multiple people work on the same repository, things can get confusing very quickly if there are no rules. Let's learn the basic branch management rules and easy-to-understand naming conventions to develop efficiently with everyone on the same page, and aim to become a master of team development!

Why Are Branch Management Rules Necessary?

What would happen if there were no rules for creating branches within a team?

Person A might create `feature-A`, Person B might create `fix-B`, and Person C might create `sato-branch`. Everyone would start creating branches with arbitrary names. In this situation, nobody would be able to tell what each branch is for. As a result, unnecessary branches would proliferate, merge mistakes would occur frequently, and development would descend into chaos.

To prevent this chaos and proceed with development smoothly, simple, shared "branch management rules (a branching strategy)" are absolutely essential for a team. While there are famous branching strategies like "Git-flow," for beginners, it's more than enough to first learn the basics of a simpler "feature branch workflow."

Basic Branch Types and Their Roles

In simple team development, we mainly use two types of branches. Let's get a solid understanding of their respective roles.

• `main` branch (formerly `master` branch)

  This is the sacred branch for storing "production-ready code that is always working properly." It is absolutely crucial to avoid editing this branch directly or introducing unstable code into it.

  【Rule】: No one should ever commit or push directly to the `main` branch. All changes should be merged through a Pull Request from a feature branch, which we'll discuss next.

• Feature Branch

  This is a working branch created to perform a specific task, such as developing a new feature, fixing a bug, or making a small improvement. It's also sometimes called a "topic branch." You branch off from the `main` branch, and when the work is complete, you merge it back into the `main` branch. It's a short-lived branch that is deleted after its work is done.

  【Rule】: No matter how small the fix, always start your work by creating a new feature branch.

Easy-to-Understand Branch Naming Conventions

To make feature branches understandable to everyone, a consistent naming convention is important. The format " `prefix/description-of-work` " is commonly used.

Types of Prefixes and Specific Examples:

• feature/: When adding a new feature
  • Example: feature/add-login-page
• fix/: When fixing a bug
  • Example: fix/correct-header-layout-bug
• refactor/: When improving code quality without changing functionality (refactoring)
  • Example: refactor/optimize-database-query
• docs/: When modifying documentation (like README.md)
  • Example: docs/update-installation-guide

If you share rules like these with your team, anyone can tell what a branch is for just by looking at its name.

In Practice! The Basic Flow of Team Development

Now, let's look at the basic flow of team development based on these rules, along with the commands.

Step 1: Get the Latest `main` Branch

Before starting any work, always update your local `main` branch to the latest state from the remote repository. First, switch to the `main` branch.

git checkout main

Next, bring the latest information from the remote to your local machine.

git pull origin main

Step 2: Create a Feature Branch for Your Work

From the up-to-date `main` branch, create a branch for your task. This time, let's create a branch assuming we are "adding a contact form."

git checkout -b feature/add-contact-form

Step 3: Make Modifications/Develop and Commit

On your newly created branch, feel free to modify or add code. When you've completed a meaningful chunk of work, create a commit.

git add .

git commit -m "Add basic structure of contact form"

Step 4: Push to the Remote Repository

Push the feature branch you created to the remote repository. This is the first time your work becomes visible to your team members.

git push origin feature/add-contact-form

Step 5: Create a Pull Request and Get it Reviewed

Once the push is complete, create a Pull Request on GitHub targeting the `main` branch. Ask your team members to review your code and give you feedback. (Refer to the previous article for how to create a Pull Request).

Step 6: After Merging, Delete the Unnecessary Branch

Once your Pull Request has been safely merged, the feature branch you used for that work is no longer needed. To keep the repository clean, let's delete it.

First, delete the remote branch. This can usually be done just by pressing the "Delete branch" button that appears on the GitHub Pull Request page after merging.

[Image: The "Delete branch" button displayed after a merge.]

Next, delete the branch that remains locally. Let's switch back to the `main` branch first.

git checkout main

And then, delete the unnecessary local branch.

git branch -d feature/add-contact-form

This completes one cycle. When you start new work, you repeat from Step 1.

Conclusion: Simple Rules Save the Team

The secret to successful development with multiple people is not learning complex rules, but rather **having everyone consistently follow simple rules**. By thoroughly implementing the basic rules introduced here as a team, your development efficiency will dramatically increase, and you can avoid unnecessary trouble.

• Always protect the `main` branch.
• Always do work in a feature branch.
• Be thorough with easy-to-understand naming conventions.
• Always merge into `main` via a Pull Request.
• Frequently delete merged branches.

With this GitHub introduction series, you have learned everything from creating an account to the basic flow of collaborative development. This is a huge step forward as a web creator. Using the knowledge you've gained here as a foundation, please try to actively use Git and GitHub in your actual projects. We hope your development life becomes more comfortable and creative!