Branching for Isolated Development

A branch is an independent line of development inside a repository. It lets you make and commit changes without placing them immediately into the main line of the project.

The main branch represents the central project line. A development, staging, or feature branch provides a separate place to experiment, build, test, and review work before combining it with main.

List the repository's branches with:

git branch

The current branch is marked with an asterisk.

Create a branch with:

git branch development

A newly created branch begins from the exact committed state of the branch you were on at creation time. If development is created while main is current, development initially points to the same project state as main.

Switch to the new branch with:

git checkout development

The working directory now reflects the files and committed state of development.

If you create a file, stage it, and commit it while on development, that commit belongs to development:

git add . git commit -m "Add 3.txt on development"

When you switch back to main:

git checkout main

The branch-specific file may disappear from the working directory because main does not contain the development commit.

Git is not deleting the work. It is changing the visible working tree to match the branch you selected.

This branch isolation applies in both directions. Main can receive its own commit while development receives a different commit. Each branch then represents a different continuation of their previously shared history.

Direct experimentation on main risks mixing unfinished work with the project's central version. Branching provides an intermediate development space.

A branch supports three forms of control:

• Isolation: Changes remain separate from main until deliberately merged.
• Attribution: Commits belong to the branch on which they were created.
• Context switching: Git changes the working files to match the selected branch.

This makes it possible to develop a feature, test an approach, or prepare a release without forcing those changes into the central branch immediately.

A basic branch workflow is:

1. Start from the branch whose current state should be copied.
2. Create the new branch.
3. Switch to it.
4. Make changes.
5. Stage and commit those changes on that branch.
6. Switch back to main to confirm that the branch work remains isolated.

git checkout main git branch development git checkout development

Create and edit the feature files, then:

git status git add . git commit -m "Implement development changes"

Return to main:

git checkout main

At this point, the development commit has not entered main. It remains available on the development branch until a merge or another integration operation is performed.

The demonstrated workflows use names such as main, development, staging, and feature.

• main is the central line.
• development holds work under active development.
• staging can represent another pre-main integration line.
• feature isolates a specific feature.

The important mechanism is not the name itself, but the separate history and working-tree view associated with each branch.

Creating a branch does not move you onto it automatically when using git branch <name>. You must switch with git checkout <name>.

Changes must be committed to become part of a branch's history. Uncommitted work is still working-directory state and can block a checkout if the target branch would overwrite it.

A branch does not affect main until its commits are merged, rebased, or otherwise integrated.

Branch isolation reduces risk, but it also creates multiple lines that eventually need coordination. That coordination is the purpose of merging, conflict resolution, remote branches, and pull requests.

Create branches to keep unfinished or experimental work independent from main. Commit on the correct branch, and remember that switching branches changes the working directory to match that branch's recorded state.