Commit df33e211 authored by Craig Norris's avatar Craig Norris

Merge branch '326486-create-master-main-source-code' into 'master'

Remove 'master' mentions from Source Code pages

See merge request gitlab-org/gitlab!62151
parents a64a5c04 d209e0ea
......@@ -11,7 +11,7 @@ A branch is an independent line of development in a [project](../user/project/in
When you create a new branch (in your [terminal](start-using-git.md#create-a-branch) or with
[the web interface](../user/project/repository/web_editor.md#create-a-new-branch)),
you are creating a snapshot of a certain branch, usually the main `master` branch,
you are creating a snapshot of a certain branch, usually the main branch,
at its current state. From there, you can start to make your own changes without
affecting the main codebase. The history of your changes is tracked in your branch.
......
......@@ -295,8 +295,9 @@ After you've done that, you can [stage your files](#add-and-commit-local-changes
To work on an up-to-date copy of the project (it is important to do this every time
you start working on a project), you `pull` to get all the changes made by users
since the last time you cloned or pulled the project. Use `master` for the
`<name-of-branch>` to get the main branch code, or the branch name of the branch
since the last time you cloned or pulled the project. Replace `<name-of-branch>`
with the name of your [default branch](../user/project/repository/branches/default.md)
to get the main branch code, or replace it with the branch name of the branch
you are currently working in.
```shell
......@@ -305,7 +306,8 @@ git pull <REMOTE> <name-of-branch>
When you clone a repository, `REMOTE` is typically `origin`. This is where the
repository was cloned from, and it indicates the SSH or HTTPS URL of the repository
on the remote server. `<name-of-branch>` is usually `master`, but it may be any
on the remote server. `<name-of-branch>` is usually the name of your
[default branch](../user/project/repository/branches/default.md), but it may be any
existing branch. You can create additional named remotes and branches as necessary.
You can learn more on how Git manages remote repositories in the
......@@ -330,14 +332,14 @@ to work on a different **branch**.
When you create a branch in a Git repository, you make a copy of its files at the time of branching. You're free
to do whatever you want with the code in your branch without impacting the main branch or other branches. And when
you're ready to bring your changes to the main codebase, you can merge your branch into the default branch
used in your project (such as `master`).
used in your project (such as `main`).
A new branch is often called **feature branch** to differentiate from the
**default branch**.
[default branch](../user/project/repository/branches/default.md).
### Create a branch
To create a new feature branch and work from without affecting the `master`
To create a new feature branch and work from without affecting the default
branch:
```shell
......@@ -348,14 +350,15 @@ Note that Git does **not** accept empty spaces and special characters in branch
names, so use only lowercase letters, numbers, hyphens (`-`), and underscores
(`_`). Do not use capital letters, as it may cause duplications.
### Switch to the master branch
### Switch to the default branch
You are always in a branch when working with Git. The main branch is the master
branch, but you can use the same command to switch to a different branch by
changing `master` to the branch name.
You are always in a branch when working with Git. The
[default branch](../user/project/repository/branches/default.md) can vary depending
on your version of GitLab, but you can alter this command to switch to a different branch by
changing `main` to the branch name:
```shell
git checkout master
git checkout main
```
### Work on an existing branch
......@@ -417,10 +420,10 @@ To push all local commits (saved changes) to the remote repository:
git push <remote> <name-of-branch>
```
For example, to push your local commits to the _`master`_ branch of the _`origin`_ remote:
For example, to push your local commits to the _`main`_ branch of the _`origin`_ remote:
```shell
git push origin master
git push origin main
```
On certain occasions, Git disallows pushes to your repository, and then
......@@ -464,14 +467,15 @@ A Git commit should not usually be reversed, particularly if you already pushed
to the remote repository. Although you can undo a commit, the best option is to avoid
the situation altogether by working carefully.
### Merge a branch with master branch
### Merge a branch with default branch
When you are ready to make all the changes in a branch a permanent addition to
the master branch, you `merge` the two together:
the default branch, you `merge` the two together, changing `<feature-branch>` and
`<default-branch>` to your values:
```shell
git checkout <name-of-branch>
git merge master
git checkout <feature-branch>
git merge <default-branch>
```
## Advanced use of Git through the command line
......
......@@ -9,7 +9,7 @@ type: how-tos
GitLab values encourage the use of [Minimal Viable Change (MVC)](https://about.gitlab.com/handbook/values/#minimal-viable-change-mvc).
However, viable changes are not always small. In such cases, it can help to set up a dedicated feature branch.
People can contribute MRs to that feature branch, without affecting the functionality of the default (usually `master`) branch.
People can contribute MRs to that feature branch, without affecting the functionality of the [default branch](../../user/project/repository/branches/default.md).
Once work on the development branch is complete, then the feature branch can be finally merged into the default branch.
......@@ -19,14 +19,14 @@ GitLab frequently implements this process whenever there is an MVC that requires
This section describes the use case with GitLab [release posts](https://about.gitlab.com/handbook/marketing/blog/release-posts/).
Dozens of GitLab team members contribute to each monthly release post.
In such cases, it may be more efficient to submit an MR on the release post feature branch instead of master.
In such cases, it may be more efficient to submit an MR on the release post feature branch instead of the [default branch](../../user/project/repository/branches/default.md).
In this case, the feature branch would be `release-X-Y`. Assuming the `release-X-Y` branch already exists, you can set up an MR against that branch, with the following steps:
1. Navigate to the main (master) branch:
1. Navigate to the [default branch](../../user/project/repository/branches/default.md) (here, `main`):
```shell
git checkout master
git checkout main
```
1. Make sure you have the latest version of your repository:
......@@ -101,8 +101,8 @@ we have selected `test-branch` as the source, and `release-13-0` as the target.
Request to merge test-branch into release-13-0
```
That confirms you've set up the MR to merge into the specified branch, not master.
That confirms you've set up the MR to merge into the specified branch, not the [default branch](../../user/project/repository/branches/default.md).
1. Proceed with the change as you would with any other MR.
1. When your MR is approved, and an appropriate user merges that MR, you can rest assured that your work is incorporated directly into the feature branch.
When the feature branch is ready, it can then be merged into master.
When the feature branch is ready, it can then be merged into the [default branch](../../user/project/repository/branches/default.md).
......@@ -80,12 +80,13 @@ ensure that the changes you're adding to the codebase do not break any
existing changes added to the target branch _after_ you created your feature
branch.
For example, to update your branch `my-feature-branch` with `master`:
For example, to update your branch `my-feature-branch` with your
[default branch](../../user/project/repository/branches/default.md) (here, using `main`):
1. Fetch the latest changes from `master`:
1. Fetch the latest changes from `main`:
```shell
git fetch origin master
git fetch origin main
```
1. Checkout your feature branch:
......@@ -94,24 +95,24 @@ For example, to update your branch `my-feature-branch` with `master`:
git checkout my-feature-branch
```
1. Rebase it against `master`:
1. Rebase it against `main`:
```shell
git rebase origin/master
git rebase origin/main
```
1. [Force-push](#force-push) to your branch.
When you rebase:
1. Git imports all the commits submitted to `master` _after_ the
1. Git imports all the commits submitted to `main` _after_ the
moment you created your feature branch until the present moment.
1. Git puts the commits you have in your feature branch on top of all
the commits imported from `master`:
the commits imported from `main`:
![Git rebase illustration](img/git_rebase_v13_5.png)
You can replace `master` with any other branch you want to rebase against, for
You can replace `main` with any other branch you want to rebase against, for
example, `release-10-3`. You can also replace `origin` with other remote
repositories, for example, `upstream`. To check what remotes you have linked to your local
repository, you can run `git remote -v`.
......
......@@ -354,7 +354,7 @@ GitLab). There is a `git merge --squash` command which does exactly that
at merge).
NOTE:
Never modify the commit history of `master` or shared branch.
Never modify the commit history of your [default branch](../../../user/project/repository/branches/default.md) or shared branch.
### How modifying history is done
......
......@@ -180,12 +180,13 @@ Git includes a complete set of [traces for debugging Git commands](https://git-s
## Rebasing
### Rebase your branch onto master
### Rebase your branch onto the default
The `-i` flag stands for 'interactive':
The `-i` flag stands for 'interactive'. Replace `<default-branch>` with the name
of your [default branch](../../user/project/repository/branches/default.md):
```shell
git rebase -i master
git rebase -i <default-branch>
```
### Continue the rebase if paused
......
This diff is collapsed.
......@@ -17,8 +17,11 @@ To access the visibility and access control options:
## Default branch protection
This global option defines the branch protection that applies to every repository's default branch. [Branch protection](../../project/protected_branches.md) specifies which roles can push to branches and which roles can delete
branches. In this case _Default_ refers to a repository's default branch, which in most cases is `master`.
This global option defines the branch protection that applies to every repository's
[default branch](../../project/repository/branches/default.md).
[Branch protection](../../project/protected_branches.md) specifies which roles can push
to branches and which roles can delete branches. In this case _Default_ refers to a
repository's [default branch](../../project/repository/branches/default.md).
This setting applies only to each repositories' default branch. To protect other branches, you must configure branch protection in repository. For details, see [protected branches](../../project/protected_branches.md).
......
......@@ -201,8 +201,8 @@ This process allows you to lock one file at a time through the GitLab UI and
requires access to [GitLab Premium](https://about.gitlab.com/pricing/)
or higher tiers.
Default branch file and directory locks only apply to the default branch set in
the project's settings (usually `master`).
Default branch file and directory locks only apply to the
[default branch](repository/branches/default.md) set in the project's settings.
Changes to locked files on the default branch are blocked, including merge
requests that modify locked files. Unlock the file to allow changes.
......
......@@ -45,7 +45,7 @@ To disable highlighting entirely, use `gitlab-language=text`. Lots more fun shen
```
Please note that these configurations only take effect when the `.gitattributes`
file is in your default branch (usually `master`).
file is in your [default branch](repository/branches/default.md).
NOTE:
The Web IDE does not support `.gitattribute` files, but it's [planned for a future release](https://gitlab.com/gitlab-org/gitlab/-/issues/22014).
......
......@@ -65,9 +65,9 @@ For an existing project, you can set up push mirroring as follows:
![Repository mirroring push settings screen](img/repository_mirroring_push_settings.png)
When push mirroring is enabled, only push commits directly to the mirrored repository to prevent the
mirror diverging.
mirror diverging.
Unlike [pull mirroring](#how-it-works), the mirrored repository is not periodically auto-synced.
Unlike [pull mirroring](#how-it-works), the mirrored repository is not periodically auto-synced.
The mirrored repository receives all changes only when:
- Commits are pushed to GitLab.
......@@ -93,14 +93,14 @@ You can also create and modify project push mirrors through the
By default, if any ref on the remote mirror has diverged from the local
repository, the *entire push* fails, and no updates occur.
For example, if a repository has `master`, `develop`, and `stable` branches that
For example, if a repository has `main`, `develop`, and `stable` branches that
have been mirrored to a remote, and then a new commit is added to `develop` on
the mirror, the next push attempt fails, leaving `master` and `stable`
the mirror, the next push attempt fails, leaving `main` and `stable`
out-of-date despite not having diverged. No change on any branch can be mirrored
until the divergence is resolved.
With the **Keep divergent refs** option enabled, the `develop` branch is
skipped, allowing `master` and `stable` to be updated. The mirror status
skipped, allowing `main` and `stable` to be updated. The mirror status
reflects that `develop` has diverged and was skipped, and be marked as a failed
update.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment