Version control gitlab
Introduction to version control
Version control refers to the management of changes in various program codes, configuration files and description documents in the process of software development. It is one of the core ideas of software configuration management.
The main function of version control is to track file changes. It faithfully records when, who changed what content of the file and other information. Each time a file is changed, the version number of the file will increase. In addition to recording version changes, another important function of version control is parallel development. Software development is often multi person collaborative work. Version control can effectively solve the problems of version synchronization and development communication between different developers, and improve the efficiency of collaborative development. The most common bug correction problem of different versions of software in parallel development can also be effectively solved by branching and merging in version control.
Specifically, in each development task, it is necessary to first set the development baseline and determine the initial development version of each configuration item. In the development process, developers develop the required target version based on the version of the development baseline. In case of demand change, the impact scope of the change shall be determined through the evaluation of the change, the version of the affected configuration item shall be modified, and the version tree of the configuration item shall continue to extend or generate new branches according to the nature of the change to form a new target version, while the configuration item not affected by the change shall not be changed. At the same time, it shall be able to record and track the impact of the change on the version. If necessary, you can also go back to the previous version. For example, when a development requirement or requirement change is cancelled, you need the ability to return the version to the development baseline version. In the process of unpacking and regrouping quarterly upgrade packages, it is actually to return the versions of some configuration items to the development baseline, recombine and merge different branches corresponding to different requirements, and form a new upgrade package version.
Version control is the core function of software configuration management. All elements placed in the configuration library shall be automatically identified with version, and the uniqueness of version naming shall be guaranteed. During version generation, it automatically branches and evolves according to the set usage model. In addition to the version information automatically recorded by the system, in order to cooperate with each stage of the software development process. We also need to define and collect some metadata to record the version auxiliary information and standardize the development process, and prepare for the measurement of software process in the future. Of course, if supported by the selected tools, these auxiliary data will be able to directly count the process data, so as to facilitate the software process improvement activities. For each baseline control item in the configuration library, the corresponding access rights should be set according to the location and status of its baseline. Generally speaking, all versions before the baseline version should be locked. If they need to be changed, they should be operated according to the change control process.
Common version control tools:
-
gitlab
-
subversion
gitlab deployment
//Turn off firewall and seLinux [root@localhost src]# systemctl stop firewalld [root@localhost src]# setenforce 0 //Install git [root@localhost ~]# yum -y install epel-release git Installation process //Install dependent packages [root@localhost ~]# yum -y install curl openssh-server openssh-clients postfix cronie policycoreutils-python-utils Installation process //Start the postfix service and set the boot auto start [root@localhost ~]# systemctl enable --now postfix Created symlink /etc/systemd/system/multi-user.target.wants/postfix.service → /usr/lib/systemd/system/postfix.service. //Download the rpm package of gitlab [root@localhost ~]# cd /usr/src/ [root@localhost ~]# wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el8/gitlab-ce-14.3.2-ce.0.el8.x86_64.rpm [root@localhost src]# ls debug gitlab-ce-14.3.2-ce.0.el8.x86_64.rpm kernels //Install gitlab [root@localhost src]# rpm -ivh gitlab-ce-14.3.2-ce.0.el8.x86_64.rpm warning: gitlab-ce-14.3.2-ce.0.el8.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID f27eab47: NOKEY Verifying... ################################# [100%] Preparing... ################################# [100%] Updating / installing... ...... *. *. *** *** ***** ***** .****** ******* ******** ******** ,,,,,,,,,***********,,,,,,,,, ,,,,,,,,,,,*********,,,,,,,,,,, .,,,,,,,,,,,*******,,,,,,,,,,,, ,,,,,,,,,*****,,,,,,,,,. ,,,,,,,****,,,,,, .,,,***,,,, ,*,. _______ __ __ __ / ____(_) /_/ / ____ _/ /_ / / __/ / __/ / / __ `/ __ \ / /_/ / / /_/ /___/ /_/ / /_/ / \____/_/\__/_____/\__,_/_.___/ Thank you for installing GitLab! .......
Modify profile
[root@localhost src]# vim /etc/gitlab/gitlab.rb ....... 31 ##! https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html 32 external_url 'http://192.168.220.9 '/ / set this as the server ip address or domain name of gitlab 33 34 ## Roles for multi-instance GitLab ....... //Reload the configuration file and restart gitlab [root@localhost src]# gitlab-ctl reconfigure