> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Understanding Branching

> Explains Git branching workflow, feature branches, merge strategies, best practices and collaboration to keep main stable and enable safe parallel development.

What is branching?

In Git, a branch represents an independent line of development. The `main` (historically `master`) branch typically contains production-ready code that’s frequently deployed. When you need to build a new feature, fix a bug, or experiment without affecting `main`, you create a feature branch. A feature branch is an isolated copy of the codebase where you and your teammates can commit, iterate, and test changes before merging them back into `main`.

<Frame>
  <img src="https://mintcdn.com/kodekloud-c4ac6d9a/1W0Ytfcz_GRwDXc0/images/GitHub-Foundations-Certification/Git-and-GitHub-Basics/Understanding-Branching/git-workflow-process-flowchart.jpg?fit=max&auto=format&n=1W0Ytfcz_GRwDXc0&q=85&s=2ab114a1ff2e734587502db8ba55926c" alt="The image is a flowchart representing a Git workflow process, illustrating the steps from coding to production, including branching, committing, reviewing, approving, merging, and deployment." width="1920" height="1080" data-path="images/GitHub-Foundations-Certification/Git-and-GitHub-Basics/Understanding-Branching/git-workflow-process-flowchart.jpg" />
</Frame>

Why branches matter

* Isolation: Implement changes without risking `main`.
* Collaboration: Multiple contributors can work on the same feature branch.
* Safer releases: Code is validated by CI and peer review before merging.
* Parallel development: Different features and fixes can be developed simultaneously.

Typical feature-branch workflow

1. Create a descriptive branch from `main`.
2. Make changes locally; commit often with meaningful messages.
3. Push the branch to the remote repository.
4. Open a pull request (PR) to merge the feature branch into `main`.
5. CI runs automated checks (tests, linters) and reviewers inspect the code.
6. Address feedback by updating the branch and pushing additional commits.
7. Once CI passes and reviewers approve, merge the branch into `main`.
8. Deploy `main` to staging or production as your release process requires.

Common Git commands for this flow:

```bash theme={null}
# Create and switch to a feature branch
git checkout -b feature/login-form

# Stage and commit changes
git add .
git commit -m "Add login form component"

# Push branch to remote and set upstream
git push -u origin feature/login-form

# Update branch from main (merge)
git checkout feature/login-form
git fetch origin
git merge origin/main

# Or rebase onto main (see warning below)
git checkout feature/login-form
git fetch origin
git rebase origin/main
```

Merge strategies

* Merge commit: preserves all commits and creates a merge commit (`git merge`).
* Squash-and-merge: combines all branch commits into a single commit on `main`.
* Rebase-and-merge: rewrites branch commits on top of `main` to create a linear history.

Table: Branch types and use cases

| Branch type    | Use case                                   | Example              |
| -------------- | ------------------------------------------ | -------------------- |
| `main`         | Production-ready code, deployed frequently | `main`               |
| Feature branch | New features, experiments                  | `feature/login-form` |
| Hotfix branch  | Critical bug fixes for production          | `hotfix/urgent-500`  |
| Release branch | Preparing a release, last-minute fixes     | `release/1.2.0`      |

Best practices

* Use short, descriptive branch names, e.g. `feature/login-form`, `fix/calc-bug-123`.
* Keep `main` deployable at all times.
* Run CI locally (or via pre-commit hooks) to reduce failing checks in PRs.
* Keep branches up to date with `main` by merging or rebasing regularly to minimize conflicts.
* Prefer small, focused pull requests for easier review.

<Callout icon="lightbulb" color="#1CB2FE">
  Use clear, short branch names (for example `feature/login-form` or `fix/calc-bug-123`) and keep `main` deployable. Run CI locally (or via pre-commit hooks) before pushing to reduce noisy failures in pull requests.
</Callout>

<Callout icon="warning" color="#FF6B6B">
  Avoid rebasing branches that are already pushed and shared with others unless your team agrees—rewriting history can disrupt collaborators. Use `merge` for shared branches, or coordinate a force-push after rebasing.
</Callout>

Keeping branches healthy

* Regularly merge or rebase changes from `main` into your feature branch.
* Address CI failures quickly and update the PR with fixes.
* Use branch protection rules (required reviews, required status checks) to enforce quality gates.

Links and references

* [Git Documentation](https://git-scm.com/doc)
* [Git Branching](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell)
* [GitHub Docs: About Branches](https://docs.github.com/en/get-started/using-git/about-branches)

Summary
Branching is a core Git workflow that enables safe, parallel development and a controlled review-and-merge process so `main` remains stable and ready for deployment. Follow naming conventions, keep branches current with `main`, and use CI and code reviews to ensure high-quality merges.

<CardGroup>
  <Card title="Watch Video" icon="video" cta="Learn more" href="https://learn.kodekloud.com/user/courses/github-foundation-certification/module/283f1e98-efc7-4003-9946-920de806da32/lesson/2141e09c-1f74-4971-b9be-47947931f60c" />
</CardGroup>
