【Practical tools】-Git+GitLab

1. Introduction to Git

1.1 What is Git?

Git is a distributed version control system used to track and manage changes to project code. It was created by Linus Torvalds in 2005 to help developers collaborate better, track code changes, and easily roll back to previous versions.

Git has many advantages over traditional centralized version control systems. It not only allows each developer to have a complete copy of the project (local repository), but also to work without relying on a central server. This enables Git to perform version control and development work even when the network connection is unstable or the server is unavailable.

1.2 The basic concept of Git

Before using Git, it is very important to understand some basic concepts.

1.2.1 Warehouse (Repository)

Git repositories are where code and version history are stored. It contains all the files of the project and the metadata associated with those files. Each project usually has a main repository, which can be created on your local computer or on a hosted service such as GitLab.

1.2.2. Commit

Committing is one of the most basic operations in Git. It represents a change to the project code. Each commit has a unique identifier (SHA-1 hash) that is used to track and reference that change.

1.2.3. Branch

A branch is a copy in Git that is used to independently develop a feature or solve a problem. By default, every project has a master branch (usually "master" or "main"), and other feature branches are created from the master branch. The benefit of branching is that it allows team members to work in parallel without interfering with each other's code.

1.2.4. Merge

Merging is the process of merging changes from one branch into another. When a function is developed or a problem is solved, the related branch can be merged back into the main branch, so that the main branch also has these changes.

1.2.5. Remote Repository

A remote repository is a copy of a Git repository stored on the network or on a server. By interacting with remote warehouses, team members can share code, collaborate on development, and push local changes to remote warehouses or pull the latest changes from remote warehouses.

1.3 Install and configure Git

Before you can start using Git, you first need to install Git and do some basic configuration.

1. Install Git: Depending on your operating system, download and install Git. Git can run on various platforms such as Windows, Mac and Linux. After the installation is complete, enter in the command line terminal git --versionto verify whether the installation is successful and view the version information of Git.

2. Configure Git: After installing Git, you need to configure your username and email address, which will appear in your commit records.

   Enter the following command in the command line terminal, replacing the username and email address with your own information:

   git config --global user.name "Your Name"
   git config --global user.email "[email protected]"
   

Now that you have installed and configured Git, you can start using Git to track and manage your project code. Next, we'll learn the basics of how to initialize a repository, make commits, and create branches.

If you are not familiar with the content of the command, you can use

git --help
以及
git help 特定指令进行查询

2. Introduction to common cloud code warehouses

In software development, the cloud code warehouse is a key tool for team collaboration and code hosting. The following introduces several common cloud code warehouse platforms: GitHub, Gitee and Huawei CodeHub.

2.1. GitHub

GitHub is the world's largest open source code hosting platform, founded in 2008. It provides an easy-to-use online Git repository management system, as well as many powerful collaboration features. Key features of GitHub include:

• Wide range of open source projects: There are millions of open source projects on GitHub, including various programming languages, frameworks and tools, etc.
• Issues and Pull Requests: Team members can report problems or make feature requests by submitting Issues. At the same time, Pull Requests allow team members to share and discuss their modifications to the project, facilitating code review and merging work.
• GitHub Actions: Provides built-in continuous integration/continuous deployment (CI/CD) tools to facilitate automatic building, testing, and deployment of projects when code is committed.
• Collaborate and socialize: Users can discuss projects, submit questions and pull requests, and follow projects of interest.

2.2. Gitee

Gitee (code cloud) is the largest code hosting platform in China, established in 2013. It is similar to GitHub, providing Git warehouse hosting and team collaboration functions. Key features of Gitee include:

• Fast access speed: Gitee server is located in China, for Chinese developers, the access speed is faster.
• Enterprise version service: Gitee provides enterprise version service, providing enterprise users with more customization and value-added functions.
• GVP (Gitee Valuable Project): Gitee provides free resources and support for some high-quality projects to help the project grow better.

2.3. Huawei CodeHub

Huawei CodeHub is a cloud code hosting platform launched by Huawei for code storage and team collaboration. It is mainly developed for Huawei internally, but it also supports the registration of personal accounts. Key features of CodeHub include:

• Enterprise-level support: Designed for large enterprises and projects, it provides safe and reliable code management and team collaboration functions.
• Global service: Huawei CodeHub servers are deployed around the world to ensure access speed and stability for global users.

Summarize

GitHub, Gitee, and Huawei CodeHub are powerful cloud code warehouse platforms that provide functions such as team collaboration, code hosting, and continuous integration, making it easy for developers to manage and collaborate on code in the cloud. According to factors such as project requirements, geographic location, and corporate policies, developers can choose a code hosting platform that suits them.

3. GitLab installation and deployment

Install GitLab on CentOS

1. Install dependent packages:

   Open a terminal and execute the following command to install GitLab's dependent packages:

   sudo yum install -y curl policycoreutils-python openssh-server postfix
   sudo systemctl enable sshd postfix
   sudo systemctl start sshd postfix
   sudo firewall-cmd --permanent --add-service=http
   sudo systemctl reload firewalld
   

   Packages such as curl, policycoreutils-python, openssh-server, and postfix are installed here, which are required for GitLab to run.

2. Add the GitLab software source and install GitLab:

   Execute the following commands in a terminal to add GitLab's software sources and install GitLab:

   curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh | sudo bash
   sudo EXTERNAL_URL="http://your-gitlab-domain.com" yum install -y gitlab-ee
   

   Note, http://your-gitlab-domain.comreplace with your actual GitLab domain name or IP address.

3. Configure and start GitLab:

   Once installed, run the following commands to configure and start GitLab:

   sudo gitlab-ctl reconfigure
   

   This will configure GitLab and start all required services.

4. Set an administrator username and password:

   Prerequisite: It is necessary to ensure that Gitlab and Redis are in the startup state at the same time. You can run gitlab-ctl startor gitlab-ctl restartcommand to start or restart.

   Execute the following command in the terminal to set the GitLab administrator username and password:

   gitlab-rails console -e production
   # 低版本可以尝试使用下面一句命令：
   gitlab-rails console production
   

   Once in the GitLab console, execute the following commands to set the administrator username and password:

   user = User.where(id: 1).first
   user.username = 'your_admin_username'
   user.password = 'your_admin_password'
   user.password_confirmation = 'your_admin_password'
   user.save!
   exit
   

   Replace your_admin_usernameand your_admin_passwordwith your own administrator username and password.

   Notice:

   GitLab enables password policy checking by default to improve account security. This check prevents the use of easily guessed or common passwords. You need to choose a stronger password that is not easily cracked.

   Here are some suggestions when creating passwords:

   1. Length: Choose a password of at least 8 characters. Longer passwords are more secure.
   2. Mixed characters: Use a combination of upper and lower case letters, numbers, and special characters. For example, use uppercase letters, lowercase letters, numbers, and special characters (eg: @#$%^&*).
   3. Avoid common words and phrases: Avoid common words, dates, personal information, and common phrases that are easy to guess as passwords.
   4. Do not reuse passwords: Avoid using the same password across multiple platforms and accounts. Use a password manager to generate and store random and unique passwords.

5. Configure the domain name:

   /etc/gitlab/gitlab.rbConfigure your domain name in the file :

   sudo nano /etc/gitlab/gitlab.rb
   

   Add the following to the file, your-gitlab-domain.comreplacing with your actual GitLab domain name or IP address:

   external_url 'http://your-gitlab-domain.com'
   

   Save the file and exit.

6. Reconfigure and restart GitLab:

   Run the following command to reconfigure and restart GitLab to make the domain name configuration take effect:

   sudo gitlab-ctl reconfigure
   sudo gitlab-ctl restart
   

Now, you have successfully installed and configured the GitLab service, and the administrator username, password, and domain name have also been set. You can access your GitLab domain name or IP address through a browser, and log in with an administrator account for further configuration and management. Please remember to modify the relevant configuration according to the actual situation, and follow the official documents and best practices for installation and configuration.

4. Git operation - Git basics

Git is a powerful version control system that helps developers track and manage code changes for projects. In this section, we'll cover the basic operations of Git, including initializing a repository, adding files, committing changes, and viewing history.

4.1. Initialize the warehouse

Before we can start using Git, we need to initialize a new local Git repository. Open a terminal in your project directory and execute the following command:

git init

This will create a new Git repository in the current directory and generate a hidden folder under the project root directory .gitfor storing Git configuration and version history information.

4.2. Adding files

we can use

git status 

View the submission and control status of files in the git directory

Before the file can be included in Git version control, we need to add the file to the staging area (Staging Area). Execute the following command to add the file:

git add <filename>

Or, if you want to add all modified files to the staging area at once, you can use the following command:

git add .

4.3. Committing changes

Once the files are added to the staging area, we can commit those changes to the local repository, producing a local version. Execute the following command to commit:

There are three submission methods:

The first method: add records manually

git commit

Then the vi tool will be opened, you need to explain the submitted content, you can use esc to exit the edit, :wq to save the edit

The second type:

git commit -m "Commit message"

Commit messageIt is the descriptive information of this submission, which can succinctly explain the content and purpose of this submission.

Note: After modifying or adding files or deleting files, you still need to execute git add and then check your status before performing git commit operation

The third type:

Two-step operations can be combined into one-step execution

git commit -am '备注'

Note that the second step can only add and submit files that have been tracked, which can be understood as adding and submitting only for modification and deletion operations

4.4. View history

Git Log is a command for viewing Git commit history. It can display the details of each commit in the project, including author, date, commit hash and commit description, etc. In this teaching note, we will introduce seven commonly used Git Log operations.

4.4.1. git log

git logcommand to display the commit history of a project. By default, it lists all commits in chronological order, with the newest commits at the top. Each commit record includes a commit hash, author, commit date, and commit description.

git log

4.4.2. git log -p -2

git log -p -2The command will display the last two commit records and show the specific changes of each commit. This makes it possible to see which modifications were introduced by each commit.

git log -p -2

4.4.3. git log --author

git log --authorcommand allows us to filter commit records by the commit author's name. This is very useful in multi-person collaborative projects, where you can quickly find an author's commit history.

git log --author="John Doe"

4.4.4. git log --oneline

git log --onelineThe command will display the commit history in a concise manner, each commit occupies only one line, and only the commit hash and commit description are displayed.

git log --oneline

4.4.5. git log --graph

git log --graphThe command can draw ASCII graphics to display the history of branch merging, so as to view the merging of branches more intuitively.

git log --graph

4.4.6. git log --pretty=oneline

git log --pretty=onelineThe command displays the commit history in a custom format, here onelinethe format is used.

git log --pretty=oneline

4.4.7. git log --pretty=format

git log --pretty=formatCommands allow us to customize the output format of the commit history in a more flexible way. We can use specific placeholders to display commit information.

git log --pretty=format:"%h - %an, %ar : %s"

The above command will display the commit history in a format similar to "commithash-authorname, relative time:commit description".

4.5 Differences between before and after modification of the tracking file

In Git, you can use git diffthe command to compare the difference before and after modification. This command can help us view the differences between the working directory and the staging area, or view the differences between the staging area and the latest commit. Two commonly used Git Diff operations are described below.

4.5.1. git diff

git diffcommand is used to compare the differences between the modifications in the working directory and the staging area. It will show the specific modification content of the file, including added, deleted and modified lines.

git diff

The above command will display the difference between the unstaged changes in the working directory and the current staging area.

4.5.2. git diff --staged或 git diff --cached

git diff --stagedThe or git diff --cachedcommand is used to compare the differences between the staging area and the latest commit. It will show the difference between the staged changes and the latest commit.

git diff --staged

The above command will show the diff between the staged changes and the latest commit.

These two Git Diff operations can help us understand the difference between before and after modifications, and help us review and understand the modifications we have made. Note that when using git diffthe command, you can restrict diffing to specific files by adding a file path parameter.

Remember that Git Diff only shows what was modified, it doesn't change any files or commit any changes. It is only used to display diff information to help developers with code review and version control

4.6 Git file ignore

In Git, we can .gitignorespecify the files and directories to be ignored through the file, and these ignored files will not be added to the version control. The following are several commonly used file ignore methods:

4.6.1. .gitignore

.gitignorefile is a text file that lists files and directories to ignore. We can add patterns in this file to match files or directories to ignore.

Example .gitignorefile content:

HELP.md
target/
!.mvn/wrapper/maven-wrapper.jar
!**/src/main/**/target/
!**/src/test/**/target/

### STS ###
.apt_generated
.classpath
.factorypath
.project
.settings
.springBeans
.sts4-cache

### IntelliJ IDEA ###
.idea
*.iws
*.iml
*.ipr

4.6.2. /node_modules

/node_modulesIndicates to ignore the directory and its contents under the project root directory node_modules. Usually, this directory contains a large number of third-party dependent libraries, which should not be added to version control, because they can be rebuilt through package.jsonand package-lock.jsonor yarn.lockfiles like this.

4.6.3. *.log

*.logIndicates to ignore all files .logwith suffixes. This is commonly used in projects to ignore log files, as log files often grow and take up space and are not suitable for inclusion in version control.

4.6.4. *.zip

*.zipIndicates to ignore all files .zipwith suffixes. This is commonly used in projects to ignore tarballs, as they may be built or used for distribution and should not be included in version control.

4.6.5. git rm -r --cached .

If some files have been mistakenly committed to version control and you want to remove them from version control but keep them in the working directory, you can use the git rmcommand's --cachedoption. This will remove the specified file from the staging area, but keep it in the local working directory.

git rm -r --cached .

The above command will delete all files in the current directory from the temporary storage area, including files submitted to version control by mistake.

Remember, before ignoring files, make sure they are not committed to version control. Because once a file is committed, .gitignoreit will no longer work on it, you need to use git rmthe command to remove it from version control.

4.7 Git restore operation

In Git, there are different commands and strategies for reverting files or commits. Below is a complete set of Git restore operations, including restoring modified files, restoring staged files, and restoring commit history.

4.7.1 Restoring Modified Files

If you made changes to a file in your working directory but haven't added it to the staging area, you can restore the file with the following command:

git checkout -- [filename]

This command will [filename]restore the file to the state it was in at the time of the most recent commit. Note that this operation will lose the modification of the file in the working directory, please confirm before executing.

4.7.2 Restoring staged files

If you have already added a file to the staging area, but want to restore it to the state of the last commit, you can use the following command:

git reset HEAD [filename]

This command will [filename]remove the file from the staging area, but keep its modifications in the working directory.

You can then restore the files in your working directory to their last committed state with the following command:

git checkout -- [filename]

This command will [filename]revert the file to its most recent commit, discarding changes in the working directory.

You can also use git checkout to restore the version to the previous content

git checkout [版本号] -- [fileName]

4.7.3 Restoring commit history

If you want to revert to a previous commit state, you can use the following command:

git log

This command will display the commit history and get the hash of the commit you want to revert.

Then, use the following command to revert to the specified commit state:

git reset --hard [commit-hash]

This command points the current branch to the specified commit, discarding all subsequent commits. Use with caution, as this will delete future commits.

Note: The operation of restoring the commit history is irreversible, please make sure you understand this, and backup your code or contact other developers of the project before performing it.

This is a complete set of Git restore operations, including restoring modified files, restoring staged files, and restoring commit history. Depending on your specific needs, choose the appropriate restore strategy to recover files or commits. Remember, before performing any Git revert operation, it is best to confirm your operation first, so as not to lose important changes or commits.

4.7.3.1. git reset --hard HEAD^

Use git reset --hard HEAD^the command to restore the HEAD pointer and working directory of the current branch to the last commit state. This command will discard the most recent commit and all subsequent commits.

git reset --hard HEAD^

The in the above command HEAD^means the last submission. By executing this command, you will roll back to the last submission status.

4.7.3.2. git reset --hard HEAD^^

Similarly, git reset --hard HEAD^^the HEAD pointer and working directory of the current branch can be restored to the penultimate commit state using the command. This command discards the last two commits and all subsequent commits.

git reset --hard HEAD^^

The in the above command HEAD^^means the penultimate submission, by executing this command, you will revert to the penultimate submission status.

4.7.3.3. git reset --hard HEAD [hashcode]

Another way is to use the commit hash to revert to a specific commit state. You can use git logthe command to get the hash of the commit you want to revert.

git log

Once you have the hash of the commit you want to revert, you can use the following command to revert it:

git reset --hard [hashcode]

in the above command [hashcode]is the hash of the specific commit you need to revert to.

Note that before performing a restore operation, make sure you have backed up important code and commits. Reverting is irreversible and will lose unsaved changes and subsequent commits

View pointer version number:

git reflog

5. Git operation - branch management

Branching is one of the most powerful features in Git, which allows you to independently develop a feature or fix a problem on a project without affecting the stability of the main branch. In this section, we'll learn how to create branches, switch branches, merge branches, and resolve merge conflicts.

In Git, branching is a very useful feature that allows us to easily manage different code versions in project development. Below is a set of commonly used Git branch manipulation commands, including creating, switching, and deleting branches.

5.1. Create a branch

To create a new branch, use the following command:

git branch [branch_name]

This will create a new branch called where the current commit is [branch_name], but you're still stuck in the current branch.

5.2. Switch branches

To switch to an already existing branch, you can use the following command:

git checkout [branch_name]

This will switch you to [branch_name]an existing branch named and change your working directory to that branch.

Or, if you want to create and switch to a new branch in one go, you can use the following command:

git checkout -b [branch_name]

This will create a new branch [branch_name]and switch your working directory to it.

5.3. Delete branch

If you want to delete a branch that has been merged, you can use the following command:

git branch -d [branch_name]

This will delete [branch_name]the merged branch named . If the branch is not merged (not yet merged into the master branch), using -dthe option will not delete, this is to prevent accidental deletion of unmerged changes.

If you are sure you want to delete unmerged branches, you can use the following command:

git branch -D [branch_name]

This will forcefully delete the [branch_name]unmerged branch named . Use -Dthe option with caution, as it will irreversibly delete the branch.

But in fact, when deleting a branch, the branch can be restored, such as describing the hash value and branch name when deleting the branch

We can create a new branch for recovery

git branch master 9cfb21e

As long as the name and hash value of the branch are consistent with the version written and deleted

5.4 Query branches

git branch

5.5 Merging branches

In Git, merging branches is the process of merging changes from one branch into another. This makes it possible to merge code and modifications on different branches into a new commit, thereby applying a feature or fix to the master branch or another target branch. The following is the general operation of merging branches:

5.5.1. Switch to target branch

First, you need to switch to the target branch you want to merge into. For example, if you want to merge the Feature branch into the main branch (usually the mainor masterbranch), you can use the following command:

git checkout main

5.5.2. Merging branches

Use the following command to merge the source branch (such as the Feature branch) into the target branch (master branch):

git merge feature

The above command will merge the changes on the Feature branch into the master branch you are currently on.

5.5.3. Resolving conflicts (if any)

Resolving conflicts when Git merges branches is a common task in development. When two branches modify the same part of the same file at the same time, Git cannot automatically determine which change should be kept, resulting in a conflict. Here are the steps to resolve merge conflicts:

5.5.3.1. Merge git merge [branch_name]with

First, use git merge [branch_name]the command to merge the target branch with the source branch. For example, to merge the Feature branch into the main branch (usually the mainor masterbranch), you can execute the following command:

git checkout main  # 切换到主分支
git merge feature  # 合并 Feature 分支到主分支

5.5.3.2. Use git statusto view the cause of the conflict

After performing the merge, if there are conflicts, you can use git statusthe command to view the conflicting files and reasons:

git status

git statusA list of conflicting files will be displayed and you will be told that the conflicts need to be resolved.

5.5.3.3. Using git merge --abortabandon merge

If you encounter problems during the merge process or want to abandon the merge, you can use git merge --abortthe command to return to the state before the merge and ignore the merge:

git merge --abort

5.5.3.4. Manually select the correct content

Open the conflicting file, and Git will mark the conflicting parts with <<<<<<<, =======and . >>>>>>>You need to manually edit the file, decide which changes to keep and how to resolve conflicts. After modifying the conflicted file, save the file.

5.5.3.5. git addAdding conflict-resolved files using

When you are done resolving conflicts, use git addthe command to mark the resolved files as resolved:

git add [resolved_file1] [resolved_file2]  # 添加解决冲突后的文件

5.5.3.6. Using git commitcommit to resolve conflicting changes

Finally, commit git committhe conflict-resolved changes with the command:

git commit -m "Resolve merge conflicts"  # 提交解决冲突后的更改

Now, the conflicts are resolved and the merge completes successfully.

5.6 View version line graph

In Git, you can use different options to view a line graph of the version history, showing the relationship between commits and branch structure. Here are a few commonly used commands to view the version line graph:

5.6.1. git log

Use git logthe command to display the complete commit history, including details of each commit, but it does not display the version line graph graphically.

git log

5.6.2. git log --oneline

Use git log --onelinethe command to display the commit history in a succinct manner, showing only one line per commit, including the commit hash and commit description.

git log --oneline

5.6.3. git log --oneline --graph

Use git log --oneline --graphthe command to display a line graph of the commit history and graphically display the branch structure.

git log --oneline --graph

5.6.4. git log --oneline --graph --all

Use git log --oneline --graph --allthe command to display a line graph of the commit history including all branches.

git log --oneline --graph --all

5.6.5. git log --oneline --graph -[number]

Use git log --oneline --graph -[number]the command to limit the number of commits displayed. Replace [number]with the number of commits you want to show, e.g. to show the last 5 commits, use:

git log --oneline --graph -5

This will display a line graph of the most recent 5 commits.

The options in the above commands --onelinewill simplify the output, making the line plots more compact and readable. And --graphthe option will display a line graph of the commit history, helping you better understand the version structure of the project.

6. Git operation - remote warehouse

A remote repository is a Git repository stored on a network or server, which allows team members to share code, collaborate on development, and keep backups of code. In this section, we'll learn how to link remote repositories, push changes, pull changes, and resolve merge conflicts.

6.1. Associate remote warehouse

Before associating a local repository with a remote GitLab repository, you need to create a blank repository on GitLab. Then, execute the following command in the local warehouse directory:

git remote add origin <remote-repository-url>

Replace <remote-repository-url>with the URL of your remote GitLab repository. This command will add a remote repository alias named in the local repository origin.

6.2. Pushing changes

When you have made some changes in the local warehouse and want to push these changes to the remote warehouse, execute the following command:

git push origin <branch-name>

This will <branch-name>push the changes from the branch to the remote repository. If you want to push all changes from your local branch to the remote repository, you can use --allthe parameter:

git push --all origin

6.3. Pulling changes

When your team members make some changes in the remote repository, and you want to fetch these latest changes, execute the following command:

git pull origin <branch-name>

This will <branch-name>fetch the latest changes from the remote repository's branch and merge them into the local branch you're currently on.

6.4. Resolving Conflicts

When pulling changes from a remote repository, conflicts sometimes occur. This is usually because your local changes conflicted with the remote repository's changes in the same location. The steps for resolving conflicts are similar to the previous steps for resolving conflicts when branches are merged.

First, Git will mark the conflict in the conflict file. You need to edit these files, resolve conflicts and save changes. Then, execute the following command to complete the merge:

git commit -m "Merge remote-tracking branch 'origin/branch-name'"

The above command commits the merged changes to the local branch.

Note: When resolving conflicts, double-check the code to make sure there are no errors, and make sure the final commit is correct.

Through the above remote warehouse operations, you can collaborate with team members on development and get the latest code changes in time. The remote warehouse makes it easier and more efficient for multi-person collaborative development, while ensuring code consistency and security. Remember to make a commit before pushing and pulling code to make sure your workspace is clean to avoid conflicts and accidental code changes.

7. GitLab operation

GitLab is a powerful code hosting platform that provides rich features to support team collaboration and continuous integration/continuous delivery. In this section, we will learn how to set up a local GitLab server, create projects, add members, use Issue to track issues and tasks, handle merge requests, and introduce the concepts of continuous integration and continuous delivery.

7.1. Build local GitLab

To build a GitLab server locally, you can use the Omnibus installation package or source code for installation. Here we take the Omnibus installation package as an example to briefly introduce the construction steps:

• Download the Omnibus installation package
• Execute the installation script and configure GitLab
• Start the GitLab service

Please note that you can refer to GitLab official documentation or other tutorials for detailed construction steps.

7.2. Creating a project

After successfully setting up the local GitLab server, you can create a new project on GitLab. Log in to GitLab, and follow the steps below to create a project:

• Click the "New Project" button in the top navigation bar
• Enter project name, description and other information
• Choose visibility and access
• Click the "Create Project" button to complete the project creation

7.3. Add members

After the project is created, you can invite others to join the project and collaborate on development. Follow the steps below to add members:

• Enter the project page, click the "Settings" tab
• Select the "Members" sub-tab
• Enter the member's GitLab username or email address
• Set the permission level of members (such as Developer, Maintainer, etc.)
• Click the "Add to project" button to invite members to join the project

7.4. Issue Tracking

GitLab provides a powerful Issue tracking function for recording and managing issues and tasks in projects. In the "Issues" tab of the project page, you can create new Issues, assign responsible persons, set priorities, tags, etc.

7.5. Merge Requests

Merge Requests is a feature in GitLab for committing and handling code merges. Developers can submit their code to the main branch by creating Merge Requests, and after review and discussion by other members, they are finally merged into the main branch.

7.6. CI/CD

Continuous Integration (CI) and Continuous Delivery (CD) are important processes in modern software development. GitLab provides built-in CI/CD tools to help you automatically build, test, and deploy projects when code is committed. Through configuration .gitlab-ci.ymlfiles, you can define CI/CD processes and automate builds and deployments.

The above are some key steps of GitLab operation. By setting up a local GitLab server, creating projects and inviting members, you can achieve collaborative development of the team. Use Issue to track issues and Merge Requests to handle code merging, making the development process more orderly and efficient. And, by configuring the CI/CD process, you can achieve continuous integration and continuous delivery, improving the speed and quality of software delivery. Remember to flexibly use GitLab's functions to support your development process according to actual needs and project scale.

7.7 Create a secret key

ssh-keygen

(2)

Then [Generating public/private rsa key pair.
Enter file in which to save the key (/c/Users/Lenovo/.ssh/id_rsa):] appears, press [Enter],

(3)

[Created directory '/c/Users/Lenovo/.ssh'.
Enter passphrase (empty for no passphrase):] will appear to prompt you to enter the password (at this time the password is invisible),

(4)

【Enter same passphrase again:】, enter the password again, press Enter,

There is a file [id_rsa.pub] in .ssh, the created key is stored here, but it cannot be opened by double-clicking,

Use the windows command line to enter the .ssh in

Use the command [more id_rsa.pub] to get the content, the following string is your key (you can copy it).

Add key in Git

1) Paste the key copied just now into the [Public Key] box, and the title can be created by yourself.