Join thousands of students achieving their dreams with expert-led courses.
Join free and unlock everything on EasyShiksha.
Takes less than 3 seconds โ no password needed
Please enter a valid email address.
Checking your emailโฆ
Almost done โ just verify your number so we can send course updates and certificates.
Used only for verification & updates
Incorrect OTP. Please try again.
Takes less than 10 seconds
Please select your country.
Please select your state.
When multiple developers work on the same software project, they often need to make changes to different features at the same time. One developer might build a login page, another might develop a dashboard, and someone else might fix a bug. If everyone makes changes directly to the same branch, coordinating the work can become difficult.
Git branches help solve this problem.
A branch allows a developer to work on a separate line of development without immediately changing the main version of the project. Once the work is ready, the developer can review and integrate the changes into the appropriate branch.
For students, interns, and junior developers, understanding Git branches is an important part of learning collaborative software development. It helps you organise your work, experiment safely, review changes, and contribute to team projects with fewer conflicts.
This guide explains Git branches from the beginning, with practical commands, examples, common mistakes, and a workflow you can practise in your own project.
Git is a version control system that records changes to files over time. It allows developers to track modifications, compare versions, and collaborate on software projects.
A Git branch is a separate pointer to a line of development. It lets you make commits independently of another branch, such as main.
Imagine that you are developing a student management application. The current version is working, but you need to add a feature that allows users to update their profiles.
Instead of making all the changes directly on main, you can create a branch named feature/profile-update and work there.
Your project might have branches such as:
main — the main line of development.
feature/login — work related to login functionality.
feature/profile-update — work related to profile editing.
fix/form-validation — a fix for a form validation issue.
These names are examples. Teams may follow different naming conventions.
The important idea is that each branch gives you a separate place to develop a set of changes. The branches can later be integrated when the work is ready.
Team members can work on separate features without constantly changing the same working version of the project.
You can test a new approach on a separate branch without immediately modifying the main branch.
A teammate can inspect the changes on a feature branch before those changes are merged.
Using separate branches for features, fixes, and other tasks makes it easier to understand the purpose of a group of changes.
Teams can protect important branches and require reviews or automated tests before changes are accepted.
Branches do not automatically prevent every problem. Developers can still create conflicts or introduce bugs. Their value comes from combining branch-based development with good commits, testing, and team practices.
Before working with branches, make sure Git is installed on your computer.
Open your terminal and run:
git --versionIf Git is installed, the command displays the installed version.
If the command is not recognised, install Git using the instructions for your operating system.
Next, move into your project directory:
cd my-projectReplace my-project with the actual directory name.
Check the current repository status:
git statusThis command shows your current branch and whether you have modified, staged, or untracked files.
If the directory is not already a Git repository, you may need to initialise it or clone an existing repository. For an existing team project, follow the team's setup instructions rather than creating a separate repository unnecessarily.
Many projects use main as their primary branch. Some older or existing projects may use a different name, such as master.
The primary branch generally represents the main line of development. Depending on the team's process, it may contain reviewed changes, tested releases, or work ready for deployment.
To see your current branch, run:
git branch --show-currentTo list local branches, run:
git branchThe current branch is marked with an asterisk.
For example:
* main
feature/login
feature/dashboardIn this example, the current branch is main.
Do not assume that every project uses the same branch structure. Before making changes, understand how your team uses its main branch and whether it has protection rules.
Suppose you need to develop a profile editing feature.
Create a branch using:
git branch feature/profile-updateThis command creates the branch, but it does not switch you to it.
To create the branch and switch to it in one step, use:
git switch -c feature/profile-updateThe -c option tells Git to create a new branch and switch to it.
You can confirm the current branch with:
git branch --show-currentThe output should be:
feature/profile-updateYou can now make changes to your project while working on this branch.
Important: Start your feature branch from the appropriate base branch. If your team expects feature branches to begin from the latest main, make sure you have updated your local branch according to the team's workflow before creating the feature branch.
Once you are on your feature branch, work on the feature as usual.
For example, you might create a React component for editing a user's profile, add form validation, or update an API integration.
After making changes, check the repository status:
git statusReview which files have changed. Then stage the files you want to include in the commit.
To stage a specific file:
git add src/ProfileForm.jsxReplace the example path with the actual file in your project.
Create a commit:
git commit -m "Add profile editing form"A commit records a snapshot of the staged changes in the repository's history.
Good commit messages describe the change clearly. For example:
Add profile update endpoint
Fix email validation on signup form
Improve dashboard loading state
Avoid vague messages such as changes, final work, or update everything.
If you have several unrelated changes, consider separating them into smaller, focused commits when practical. This makes the history easier to review.
Remember that creating a branch does not automatically save your work. Commits are what record your changes in Git history.
You may need to switch branches to review another feature, test a fix, or return to your previous work.
Use:
git switch mainTo return to your feature branch:
git switch feature/profile-updateGit switches the working tree to reflect the selected branch, provided the operation can be completed safely.
If you have uncommitted changes, Git may prevent the switch when it would overwrite those changes. Review your status before switching.
Depending on the situation, you can commit the work, safely stash it, or resolve the working-tree changes before continuing.
Avoid deleting files or discarding modifications just to force a branch switch. You may lose work that has not been committed.
A local branch exists on your computer. If you want to share it with your teammates through GitHub, GitLab, or another remote repository, you generally need to push it.
For example:
git push -u origin feature/profile-updateHere:
git push sends commits to a remote repository.
origin is a commonly used name for the remote.
feature/profile-update is the branch you want to push.
-u sets the upstream relationship for convenient future pushes and pulls.
The remote name may differ in your project, and the repository must be configured with the correct remote URL and permissions.
After the initial push, you can usually use:
git pushto push further commits from that branch.
If the push is rejected, read the error message. The problem could involve permissions, authentication, branch protection, or remote changes that need to be integrated first.
Do not force-push a shared branch unless you understand the consequences and your team's rules permit it.
After your feature is ready, you can open a pull request on a platform such as GitHub. Other platforms may use the term merge request.
A pull request proposes integrating changes from one branch into another.
For example:
feature/profile-update → main
A useful pull request description explains:
What was changed.
Why the change was needed.
How it was tested.
Whether there are limitations or known issues.
Which screenshots or other evidence help reviewers.
Teammates can review the code, leave comments, request improvements, and approve the changes according to the team's process.
You should address relevant review feedback before merging. A pull request is not just a button for combining code; it is also an opportunity to check quality and share knowledge.
For students building practical work samples, documenting what changed and how it was tested can make project evidence easier to understand. EasyShiksha's article on the pre-employment evidence layer for job-ready students discusses organising work samples and explaining the work behind them.
Merging integrates changes from one branch into another.
Suppose your profile feature has been reviewed and approved. If your team permits merging locally, a basic workflow could look like this:
First, switch to the target branch:
git switch mainThen update it according to your team's workflow and merge the feature branch:
git merge feature/profile-updateThe result depends on the history of the branches. Git may perform a fast-forward merge, create a merge commit, or report conflicts that need to be resolved.
In a team using pull requests, you may instead merge through the hosting platform after required checks and reviews have passed.
Do not merge unreviewed changes into a protected production branch simply because the command succeeds. Follow the project's review and release process.
A merge conflict occurs when Git cannot automatically combine changes.
For example, two developers might edit the same lines in the same file. Git may need a person to decide which changes should remain.
Imagine that one developer changes a heading to Welcome to the Dashboard, while another changes the same heading to Your Student Dashboard.
Git may display conflict markers similar to these:
<<<<<<< HEAD
Welcome to the Dashboard
=======
Your Student Dashboard
>>>>>>> feature/dashboard-titleThese markers show the conflicting sections. The exact labels depend on the operation and branch names.
To resolve the conflict:
Open the affected file.
Review both versions and understand the intended behaviour.
Edit the file to produce the correct final content.
Remove the conflict markers.
Test the resulting code.
Stage the resolved file.
Complete the merge or other Git operation as instructed by Git.
For example, the final heading might be:
<h1>Your Student Dashboard</h1>That is only an illustrative choice. In a real project, the correct result depends on the design and requirements.
After resolving the file, you might run:
git add src/Dashboard.jsxThen complete the merge according to the instructions shown by Git. A normal merge may require a merge commit; other operations, such as a rebase, have a different completion process.
Do not delete conflict markers without reviewing the changes. Doing so can remove important functionality or silently discard another developer's work.
Also, not every merge requires manual conflict resolution. Git can combine many changes automatically when they do not conflict.
While you are developing a feature, the target branch may receive changes from other developers.
For example, your teammate may update the shared API service while you are working on a profile page that depends on it.
If your feature branch remains based on an older version, you may discover integration problems later.
A common approach is to fetch updates and integrate the latest target branch into your feature branch.
For example:
git fetch origin
git switch feature/profile-update
git merge origin/mainThis sequence fetches remote updates and then merges the fetched main branch into your feature branch.
The exact approach depends on the team's workflow. Some teams prefer rebasing a feature branch instead of merging the target branch into it.
Rebasing replays commits onto a new base and can create a cleaner linear history, but it changes commit identities. Avoid rebasing commits that other people are already relying on unless the team explicitly agrees to that workflow.
If you are a beginner working on a shared project, follow the method your team has chosen rather than mixing merge and rebase strategies without understanding their effects.
The following example shows a typical feature workflow. Your team may use different naming conventions, review requirements, or merge strategies.
Start from the appropriate version of the project
Keep the new work separate
Record focused changes with clear messages
Share the work for review
Address problems before integration
Integrate approved changes and verify the result
This process keeps development work organised and makes it easier for the team to understand what is changing.
Before changing files, run:
git branch --show-currentThis simple habit can prevent accidental changes to the wrong branch.
Names such as test, new, or changes may not communicate the branch's purpose. Use descriptive names that follow your team's conventions.
Examples include:
feature/student-registration
fix/login-validation
docs/setup-guide
Mixing multiple unrelated tasks in one commit can make review and troubleshooting harder. Keep commits focused when practical.
A commit on your computer is not automatically available to teammates. Push your branch when you need to share your work.
A merge may complete successfully even when the combined application contains a bug. Run the relevant tests and follow the team's verification process.
Force-pushing can replace remote branch history. It may disrupt collaborators, especially when used on shared branches. Use it only when appropriate and permitted by the team's workflow.
Before deleting a feature branch, confirm that its changes have been integrated or are otherwise safely preserved. A local branch may be the only convenient reference to work that has not been merged.
You can practise Git branches using a small personal project or a test repository. Avoid experimenting with destructive commands on a shared work repository.
Try this exercise:
Create or open a Git repository.
Make sure your starting changes are committed.
Create a branch named feature/about-page.
Add a simple About page to the project.
Commit the changes with a descriptive message.
Switch back to your starting branch and inspect the files.
Switch to feature/about-page and confirm that your changes are present.
Push the feature branch to a remote repository if one is configured.
Open a pull request if you are practising with a hosting platform.
Merge the changes in your test project and verify the final result.
Use these commands as a starting point:
git status
git switch -c feature/about-page
git add .
git commit -m "Add about page"
git switch main
git switch feature/about-pageThe example assumes that main exists and that you have configured Git appropriately. Replace branch names where necessary.
The git add . command stages changes throughout the current directory, so inspect git status first and make sure you are not accidentally including secrets, generated files, or unrelated work. For greater control, stage specific files.
When you finish the exercise, try creating a second feature branch and making a change to a different file. Compare the branch histories and practise integrating the changes.
Git is a version control system that tracks changes in a repository. GitHub is a hosting and collaboration platform that provides remote repositories, pull requests, code reviews, and related tools. Git can also be used with other hosting platforms or entirely locally.
They can, but teams often use separate feature branches because they make changes easier to isolate, review, and test. The best approach depends on the team's workflow and project requirements.
A Git branch is a lightweight reference to a commit rather than a separate full copy of the entire repository. Switching branches updates the working tree to reflect the selected branch.
Git may merge the changes automatically if they can be combined safely. If it cannot determine how to combine overlapping changes, it reports a merge conflict that must be resolved.
Many teams delete merged feature branches to keep the branch list tidy. Before deleting one, confirm that the work is safely integrated and that the branch is no longer needed.
Yes. Understanding branches, commits, pushing changes, pull requests, and merge conflicts helps beginners collaborate more effectively and follow common software development workflows.
Git branches provide developers with a structured way to work on features, fixes, and experiments without immediately changing the main line of development.
To use them effectively, learn how to create a branch, check out the correct version, commit focused changes, push work to a remote repository, participate in pull requests, and resolve merge conflicts carefully.
Most importantly, practise these commands in a test repository before using unfamiliar workflows on a shared project. Understand your team's branching rules, review changes before merging, and never discard another developer's work simply to resolve a conflict quickly.
As you gain experience, Git branching will become a routine part of your development process. It will help you organise your work, collaborate with teammates, and contribute more confidently to real software projects.
More News Click here
Discover thousands of colleges and courses, enhance skills with online courses and internships, explore career alternatives, and stay updated with the latest educational news..
Gain high-quality, filtered student leads, prominent homepage ads, top search ranking, and a separate website. Let us actively enhance your brand awareness.
Download EasyShiksha Mobile Apps from Android Play Store, Apple App Store, Amazon App Store, and Jio STB.
1 million+ย learned on the EasyShiksha App
Trusted by Standards & Global Compliance Frameworks
Built under internationally recognized standards for quality, information security, educational excellence and business continuity.
ISO 9001:2015 | ISO/IEC 27001:2022 | ISO 21001:2018 | ISO 22301:2019 | DPIIT Recognized Startup | MSME Registered
