Introduction

A Git branch is an independent line of development inside the same repository. Branches allow you to work on a feature, bug fix, experiment, or documentation update without immediately changing the project’s main line of development. The files may start with the same content as the main branch, but each branch can receive different commits after it is created.

The main benefit is controlled parallel work. One person can develop a login feature while another fixes a spelling error, and neither person needs to place unfinished work directly on the main branch. Branches do not create a completely separate copy of the entire repository in the usual workflow. Instead, Git records a movable reference to a sequence of commits and updates the working directory when you switch branches.

A branch is not a backup by itself. It is a pointer to commits, so important work still needs meaningful commits and, when collaboration requires it, a push to the shared GitHub repository. A useful branch should represent a clear task, such as adding-search, fixing-header, or update-readme. Clear names make the project history easier to understand.

Creating and Switching Branches

Before creating a branch, inspect the current state of the repository. You should know which branch you are on and whether you have uncommitted changes. Starting from an unexpected branch or carrying unrelated edits can make later merges confusing.

git status
git branch
git switch main
git pull origin main
git switch -c feature-login

The status command reports modified, staged, and untracked files. The branch command lists local branches and marks the current branch. The switch command changes the working directory to main. Pulling updates the local main branch from the GitHub remote named origin, assuming the remote is configured and the branch tracks that remote. Finally, switch with the c option creates a new branch and immediately moves to it.

After the final command, new commits will belong to feature-login rather than main. Check the active branch again when a task begins, especially in a repository with several similar branches. If the repository uses a different primary branch name, such as master, use that actual name instead of main.

A common error occurs when Git refuses to switch because local changes would be overwritten. This means the working directory contains edits that are not safely represented in a commit. Review the edits first. You can commit them if they belong to the current task, temporarily stash them if they are unfinished, or discard them only when you are certain they are unnecessary. Do not use discard commands as a general way to solve the error because they can permanently remove work.

Making and Reviewing Changes

Once the feature branch is active, edit the project normally. The important rule is that the branch does not automatically commit anything. Git notices file changes, but you must inspect and record them explicitly. A focused commit should describe one logical change and should not include unrelated formatting or temporary files.

git status
git diff
git add src/login.js
git status
git commit -m "Add login form validation"

The first status command identifies changed files. The diff command displays the unstaged line-by-line changes, which helps you catch accidental edits before committing. The add command stages one selected file; you can stage several files when they belong to the same task. The second status command confirms what is staged. The commit command creates a permanent point in the branch history with a message describing the result.

After committing, Git usually reports the new commit identifier, the number of files changed, and the number of lines added or removed. If Git reports that there is nothing to commit, the changes may already have been committed, may not have been saved by the editor, or may be ignored by repository rules. If Git asks for an author identity, configure the name and email associated with your commits before continuing.

You can inspect the recent branch history to verify the result. The important check is that the feature commit appears on feature-login and that main has not changed. This separation is what makes the branch useful for review and safe integration.

Merging a Branch

Merging combines the history of one branch into another. The destination branch matters: if you want a feature included in main, switch to main first, then merge the feature branch. Merging while still on the feature branch would attempt to combine changes into the wrong destination.

git switch main
git pull origin main
git merge feature-login
git status
git log --oneline --decorate --graph -5

The initial switch changes the destination to main. Pulling first reduces the chance that the local main branch is behind the shared GitHub branch. The merge command asks Git to integrate the commits from feature-login into the current branch. If the two branches changed different files or different lines, Git may complete the merge automatically. Git can perform a fast-forward merge when main has no new commits since the feature branch was created. In other cases, Git may create a merge commit that records how the histories were joined.

The status command confirms whether the merge completed cleanly. The log command provides a compact visual history, including branch names and recent commits. After a successful local merge, test the project before pushing. A merge can be structurally valid while still exposing an application bug caused by the combined changes.

When the branch is no longer needed, it can be removed locally after the merge has been verified.

git branch -d feature-login
git push origin main

The delete command normally refuses to remove a branch whose commits have not been merged, which protects unintegrated work. The push command publishes the updated main branch to GitHub. In a team workflow, you may push the feature branch instead and open a pull request rather than merging locally. The underlying concepts remain the same: review the independent work, resolve any conflicts, and integrate it into the destination branch.

Resolving Merge Conflicts

A merge conflict occurs when Git cannot safely choose between competing changes. For example, both main and feature-login may have modified the same lines in a file. Git stops the merge and marks the affected file with conflict markers. This is not a data loss message by itself; it is a request for a human decision.

git status

Open each conflicted file and decide which content should remain. Conflict markers identify the competing sections, but they are instructions for you, not valid final application content. Remove the markers and edit the file into the correct result. You may keep one side, combine both sides, or rewrite the section based on the intended behavior. Then run the relevant tests or checks before recording the resolution.

git add path/to/resolved-file
git status
git commit -m "Merge feature-login into main"

Staging the resolved file tells Git that the conflict has been handled. The status output should no longer list that file as unmerged. A commit completes the merge when Git requires a merge commit. If the conflict resolution is wrong or the merge should not continue, you can cancel the in-progress merge with the appropriate abort command before committing.

git merge --abort

The abort command returns the repository to its state before the merge began when Git can restore that state safely. It does not replace careful review of uncommitted work. In collaborative projects, a pull request is often preferable because another person can inspect the conflict resolution and automated checks can run before main is updated.

Practical Workflow and Summary

A reliable branch workflow starts from an updated main branch, creates a task-specific branch, and keeps all related commits on that branch. Review the diff before each commit, use messages that explain the change, and check the branch name before commands that change history. Small, focused commits make review, debugging, and conflict resolution easier.

The complete sequence is conceptually simple. Create and switch to a branch for independent work. Edit files, inspect the diff, stage the intended files, and commit. When the work is ready, update main, switch to main, merge the feature branch, run tests, and publish the result or open a pull request. Branches isolate change; merging deliberately brings that change back into the project’s main history.

The most common mistakes are merging from the wrong branch, forgetting to update main, committing unrelated files, and treating conflict markers as final content. Git provides status, diff, log, and merge controls to make these mistakes visible. Use those checks as part of the workflow rather than waiting until the repository is difficult to repair.