lucasvbr/first-contributions
1
0
Fork 0
mirror of https://github.com/LucasVbr/first-contributions.git synced 2026-05-14 01:31:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update why-using-branches.md

Browse Source
This commit is contained in:
Aryaman-Mann
2025-03-26 07:37:33 +05:30
committed by GitHub
parent a626f9955b
commit 3f1984876f
1 changed files with 57 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/additional-material/git_workflow_scenarios/why-using-branches.md
+57 -35
View File
@@ -1,53 +1,75 @@
# WHY USING BRANCHES DURING CONTRIBUTING
## Why Use Branches When Contributing?
Git branches are an essential tool for collaboration in software development. They allow multiple developers to work on different features or bug fixes simultaneously without interfering with the main project code. By using branches, you can experiment freely, test new ideas, and merge only the best changes into the main project.
## What are branches.
## What Are Branches?
A **branch** in Git is essentially a separate line of development. It allows you to create an isolated version of the project where you can make changes without affecting the main codebase. When you're ready, you can merge your branch back into the main project.
Branches are simply pointers to a commit.
### How Branches Work
Every branch is just a pointer to a specific commit in the project history. When you create a new branch, Git duplicates the state of the current branch, allowing you to work independently. New commits are added to this branch's history without affecting the main branch.
When you branch out, git is essentially making a new state of your current code, upon which you can work, without affecting the important main state of the code (which is in master branch).
- To switch between branches, use `git checkout`.
- To combine changes from one branch into another, use `git merge`.
When you are happy with your experiments, and want to merge you experiments in main code, you run git merge
<branch name> master.
This will tell git, to add in all changes from your experiment branch into master.
## Why Use Branches?
Branches make collaboration **structured and efficient**. Without them, all changes would be made directly to the main project, leading to confusion, errors, and conflicting code.
This way, while working in an open source project with a number of contributors, it becomes easy to merge the best suited code without altering the main code or master branch.
### Example: The Car Paint Job Analogy
Imagine a car manufacturing team deciding on the default color for a new car model. Initially, the car is set to be **olive green**. However, a few team members want to see how it looks in **red**.
## How it works?
- Instead of repainting the original car, they create a **prototype** with red paint.
- If the red color is approved, it replaces the original color (i.e., the branch is merged into the main project).
- If the red color is rejected, the prototype is discarded (i.e., the branch is deleted).
A branch represents an independent line of development. Branches serve as an abstraction for the edit/stage/commit process. You can think of them as a way to request a brand new working directory, staging area, and project history. New commits are recorded in the history for the current branch, which results in a fork in the history of the project.
Similarly, in Git, branches allow developers to test new features without directly modifying the main codebase.
The git branch command lets you create, list, rename, and delete branches. It doesn’t let you switch between branches or put a forked history back together again. For this reason, git branch is tightly integrated with the git checkout and git merge commands.
## Feature Branching
Instead of having one branch per developer, it's better to create **one branch per feature**. This keeps things organized and prevents unnecessary conflicts.
## Why to use branches?
### Example: Alice & Bob's Feature Development
- **Alice** is working on **Feature A** and makes several commits.
- She then switches to **Feature C** and makes more commits.
- Meanwhile, **Bob** finishes **Feature B** and wants to start working on **Feature A**.
- Bob pulls in Alice’s branch, but now his branch contains **Feature A, Feature B, and some incomplete parts of Feature C**.
- When he tries to merge his branch, he faces conflicts because Feature C is unfinished.
If the question "Why do we use branching in version control like git?" still persists in your mind, here's a quick explanation:
To avoid this:
- Alice should have separate branches for **Feature A** and **Feature C**.
- Bob should have separate branches for **Feature B** and **Feature A**.
Let's take a simple example to understand the branching strategy. A production car needs a paint job before its launch. Prior to its official sale, it was decided that the car would come in 'olive green' color as default. But some of the members in the manufacturing team decided to showcase the car in 'red' color. Hence an ambiguous situation arises and to avoid this problem branching was introduced.The red color paint job is like a branch to the master repository 'Car'. Pushing this branch will suggest the red color. If merged with the master repository the car will get the red color otherwise it will continue with olive green. Merging a contributors branch to the master repo of the organization depends on the project head.
This way, they can work without interfering with each other's progress.
## Example
Alice is working on Feature A and Bob is working on Feature B. Alice is halfway done with Feature A and has made a few commits in alice. However, Feature A is quite hard to implement so Alice decides that she should rather work on Feature C and makes a few commits onto alice. Bob finished Feature B and decides that he would like to tackle Feature A and so pulls alice into bob.
After Bob finishes Feature A he would like to merge bob into master. However, bob now contains Feature A, Feature B and parts of Feature C, but Feature C is not ready to be merged! It's easy to see that a workflow like this can lead to many confusing merge conflicts.
The trick is that instead of having personal branches one should have feature branches. Alice should have a branch for Feature A and Feature C and Bob should have a branch for Feature B and Feature A. That way they both can work on different features without tramping on each other's toes.
## How to create branches?
#### Create a branch
## Creating and Managing Branches
### Create a New Branch
```sh
git branch my-new-branch
```
git branch AnyBranchName
This creates a new branch named `my-new-branch` without switching to it.
### Switch to a Branch
```sh
git checkout my-new-branch
```
This moves you to `my-new-branch`, allowing you to work on it.
A new branch will be created named AnyBranchName and all the file changes in this branch will not be affected in the main branch.
For detailed explanation refer [How to create branch](https://www.atlassian.com/git/tutorials/using-branches)
#### Delete the branch
```
git branch -d AnyBranchName
### Create and Switch to a Branch (Shortcut)
```sh
git checkout -b my-new-branch
```
This creates and switches to the new branch in a single step.
Branch name AnyBranchName will be deleted from the git repository.
Refer to [Removing branch from your repository](https://github.com/jashnimje/first-contributions/blob/7dcae72208e4b42fcf834b4f189fa8ee78238077/additional-material/git_workflow_scenarios/removing-branch-from-your-repository.md)
### Delete a Branch (After Merging)
```sh
git branch -d my-new-branch
```
This removes `my-new-branch` if it has already been merged.
### Force Delete a Branch (Without Merging)
```sh
git branch -D my-new-branch
```
Use this with caution! It deletes the branch even if it has unmerged changes.
## Additional Resources
- [Git Branching Guide (Atlassian)](https://www.atlassian.com/git/tutorials/using-branches)
- [Removing a Branch from Your Repository](https://github.com/jashnimje/first-contributions/blob/7dcae72208e4b42fcf834b4f189fa8ee78238077/additional-material/git_workflow_scenarios/removing-branch-from-your-repository.md)