Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(branch-management): add branch management readme.md #13

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 55 additions & 0 deletions Developer/development/version control/2.branch-managment.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
# Branch Management

Adhering to best practices for branch management is crucial to ensure a smooth development process. Following proper conventions can help maintain an organized codebase, reduce merge conflicts, and streamline collaboration between team members.

## Branch Strategy ##

The main idea behind the Git flow branching strategy is to isolate your work into different types of branches. There are five different branch types in total:
- Main
- Develop
- Feature
- Release
- Hotfix

The two primary branches in Git Flow are main and develop. There are three types of supporting branches with different intended purposes: feature, release, and hotfix.

## Protected Branch ##

To prevent accidental deletion or unwanted changes to primary branches like main or develop, you can implement branch protection policies on your remote repository. provide options to configure branch protection rules.

- Requiring pull requests and code reviews before merging changes
- Enforcing status checks (e.g., passing tests or successful builds) before a merge is allowed
- Restricting direct pushes to the protected branch
- Disallowing force pushes and branch deletions

## **The branch formatting should be structured as follows**

```
<type>/<scope>
```

## **Type**

| Type | Description |
| -------- | ----------------------------------------------------- |
| feature | new feature |
| hotfix | fix bug |
| release | versions of production code have been deployed |

## **Scope**

Scope is the main purpose of telling what to do with this branch. it is a broad description to give a picture of what needs to do with this branch.

## **Example**

```
feat/product-management
```

```
hotfix/user-profile
```

```
release/v1.0.1
```