Suggest an editImprove this articleRefine the answer for “What is the main branch of a project?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)**The main branch of a project** in Git is the primary "anchor" branch of the repository, around which all development is organized. **Key point:** it is most often called `main` (historically `master`) and holds the baseline version of the project that the team, CI/CD, and releases rely on.Shown above the full answer for quick recall.Answer (EN)Image**The main branch of a project** in Git is the **primary "anchor" branch of the repository**, around which all development is organized. It usually holds the **baseline version of the project** that the team, CI/CD, and releases rely on. Most often it is called `main` (historically `master`). ## How to tell that a branch is "the main one" This is not a special branch type inside Git; technically it is a **regular branch**. What makes it "main" is **team agreement and repository configuration**: - it is treated as the **source of truth** (baseline) for the project; - feature/fix branches most often **branch off** it; - verified changes are usually **merged into** it via merge/rebase; - **access rights, PR/MR rules, and CI checks** are often tied to it. ## What it is for ### 1) A stable anchor point The main branch should reflect a state that: - can be built, - can be tested, - can often be deployed. That is why teams try to keep it **in as working a state as possible**. ### 2) A shared point for integrating changes Development almost always happens in parallel: one person works on a feature, another on a bugfix, a third on a refactor. The main branch is where changes: - are **brought together**, - go through checks, - become part of the shared product. ### 3) A basis for releases and versioning In many processes, a release is made "from main": - tags are set (for example, `v1.4.0`); - artifacts are built; - deployment pipelines are triggered. ## Approaches to the "main" branch The choice depends on the development process: ### Option A: `main` = always ready for production - only what can be shipped lands in `main`; - features go through `feature/*` branches, then a PR/MR, checks, and a merge. ### Option B: `main` = an integration branch, while production comes from `release/*` or `stable` - `main` can be "livelier" and change more often; - production stability is ensured by a separate release branch. In practice, teams more often lean toward option A, because it is simpler and enforces discipline. ## How it relates to branches, HEAD, and remote repositories - **Locally**, you have a `main` branch. - **Remotely**, there is, for example, `origin/main`. - When people say "the main branch", they usually mean the **default branch on the server** (the one that opens first when you enter the repository) and its local counterpart. - `HEAD` usually points to the current branch; if you are on `main`, then `HEAD → main`. ## What is usually accepted around the main branch (in practice) - **Direct commits** to the main branch are often forbidden. - Changes get there through a PR/MR with: - review, - automated tests, - linters, - a build, - quality checks. - Commits are kept meaningful, and the history readable. ## Short definition **The main branch of a project** is the branch considered the **primary and baseline** one, containing the **current stable version**, and serving as the **integration point** for all completed changes; it is most often called `main` (or `master`).For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.