1. Create a group
1. Use the root administrator authority to create a group. A group contains multiple project branches. Users can be added to the group to set permissions. Different groups have different permissions.
2. Enter the group name, description, and visibility level, and click Create Group
2. Create a user
1. Ordinary users can only access projects belonging to their own groups, and administrators can access projects of all groups
2. Enter the user name and email address, and select ordinary user or administrator authority for permission setting
3. Click Edit again to change the password
4. Enter password
5. Add the user to the group
6. After adding, set the permissions, 5 kinds of permissions
- Guest: Can create issues, post comments, but cannot read and write the repository
- Reporter: Code can be cloned but cannot be submitted. QA and PM can grant this permission
- Developer: You can clone code, develop, submit, and push. Ordinary development can grant this permission
- Maintainer: Can create projects, add tags, protect branches, add project members, edit projects, core development can grant this permission
- Owner: You can set project access permissions - Visibility Level, delete projects, migrate projects, manage group members, and the development team leader can grant this permission
3. Project creation and GitLab operation
1. Log in to GitLab as the user you just created to create a project
When logging in for the first time, the new user is prompted to change the password, and the previous password can also be used
2. Click Create a project to create a new project
3. Create projects with your own group
Permissions are divided into three visibility levels: private, internal, and public
- Private: Project access must be explicitly granted to each user. If the item is in a group, group-group members will be granted access.
- Internal: The project is accessible to all users logged into the current GitLab server.
- Public: The project allows anyone to access it.
4. After the creation is complete, you can see the following interface
5. Now create projects in this group.
6. Select the group that the project belongs to. Since the group is private, the project is also private.
7. Import the code into the project
The project has been created, and the local code must be submitted.
Create a new repository: Create an empty repository, then start developing in the repository, and then submit it. Push an
existing folder: After creating the repository, the code already exists, and submit it directly
Download the repository, and create a file commit in the repository.
8. Create a branch
9. Backbone/feature development
For trunk development , everything is the master branch. No matter how many features come later, the submitted code is submitted to the trunk branch.
Feature branch development : Some requirements come, which requires the creation of feature feature branches based on the master branch. These new requirements codes are all in the feature branch. After the feature branch is developed, the code is submitted, and then the pipeline is triggered. These pipelines are used to verify the feature branch. If there is no problem with the verification, then the feature branch needs to do other operations. The code was merged into the master branch and released.
Feature branch development
- Create a version branch (release-1.1.1) based on the master trunk branch
- Create feature branches (feature-1, feature-2...) based on the master branch
- After the development of the feature branch is completed, merge the feature branch into the version branch
- Publish based on the version branch (dev environment, local verification, UAT, pre-production, production) It’s okay to release the production, then merge the version branch into the main branch
- Create a label tag based on the master trunk branch
10. Pull feature branch
为什么要拉取分支？ 一个分支不够吗？Generally, we use the master trunk branch to store the latest code that can be released for production, and create some feature branches separately as development branches for project requirements tasks.
The advantage of this is to prevent the pollution of the main branch and protect the branch.
Next, enter the demo-hello-service project home page, and then create a feature branch feature-1-DEV based on the main branch master. The operation is as follows:
11. Feature branch development and submission
12. Feature branch merge operation
Merge the feature branch feature-1-DEV code into the main branch master Merge Request.
On this page, select the source branch and the target branch.
On this page:
- Specifies the title of the merge request
- Descriptive information, generally change information
- Designated supervisor to review (ultimately this user decides whether to merge)
- Assign colleagues to conduct code reviews
- After the merge is successful, delete the source branch (you must delete the source branch at the end, you can keep a version before deleting it, it is best to uncheck it here)
After a merge is submitted, it is reviewed by an administrator for the merge.
At this point, a basic project development submission code process has been completed. (Be more familiar with the process)
4. Move an existing GitLab project into a new subgroup | Project
You can do this in the left sidebar under Settings->General->Transfer project. However, you will need administrative rights to the group you are transferring to.
注意： 这里需要注意的是项目移只有 Owner 才有权限操作
GitLab operation permissions:
- 1.Guest: Can create issues, post comments, but cannot read and write the repository
- 2. Reporter: You can clone the code, but you cannot submit it. QA and PM can grant this permission
- 3.Developer: Can clone code, develop, submit, push, normal development can grant this permission
- 4.Maintainer: You can create projects, add tags, protect branches, add project members, edit projects, core development can grant this permission
- 5.Owner: You can set project access permissions - Visibility Level, delete projects, migrate projects, manage group members, and the development team leader can grant this permission
