Version control gitlab

1. 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

2. Deploy gitlab

connect: https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el8/gitlab-ce-14.3.2-ce.0.el8.x86_64.rpm

[root@gitlab ~]# systemctl disable --now firewalld
Removed /etc/systemd/system/multi-user.target.wants/firewalld.service.
Removed /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.
[root@gitlab ~]# setenforce 0
[root@gitlab ~]# vi /etc/selinux/config 
[root@gitlab ~]# yum -y install epel-release vim
[root@gitlab ~]# yum -y install git curl openssh-server openssh-clients postfix cronie policycoreutils-python-utils
[root@gitlab ~]# systemctl enable --now postfix
Created symlink /etc/systemd/system/multi-user.target.wants/postfix.service → /usr/lib/systemd/system/postfix.service.
[root@gitlab ~]# ss -antl
State      Recv-Q     Send-Q         Local Address:Port          Peer Address:Port     Process     
LISTEN     0          128                  0.0.0.0:22                 0.0.0.0:*                    
LISTEN     0          100                127.0.0.1:25                 0.0.0.0:*                    
LISTEN     0          128                     [::]:22                    [::]:*                    
LISTEN     0          100                    [::1]:25                    [::]:*     
[root@ localhost ~]# cd /usr/src/
[root@localhost src]# ls
debug  kernels
[root@gitlab src]# ls
debug  gitlab-ce-14.3.2-ce.0.el8.x86_64.rpm  kernels
[root@gitlab src]# rpm -ivh gitlab-ce-14.3.2-ce.0.el8.x86_64.rpm 
[root@gitlab 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: head V4 RSA/SHA256 Signature, secret key ID f27eab47: NOKEY
Verifying...                          ################################# [100%]
In preparation...                          ################################# [100%]
Upgrading/install...
   1:gitlab-ce-14.3.2-ce.0.el8        ################################# [100%]
It looks like GitLab has not been configured yet; skipping the upgrade script.

       *.                  *.
      ***                 ***
     *****               *****
    .******             *******
    ********            ********
   ,,,,,,,,,***********,,,,,,,,,
  ,,,,,,,,,,,*********,,,,,,,,,,,
  .,,,,,,,,,,,*******,,,,,,,,,,,,
      ,,,,,,,,,*****,,,,,,,,,.
         ,,,,,,,****,,,,,,
            .,,,***,,,,
                ,*,.
  


     _______ __  __          __
    / ____(_) /_/ /   ____ _/ /_
   / / __/ / __/ /   / __ `/ __ \
  / /_/ / / /_/ /___/ /_/ / /_/ /
  \____/_/\__/_____/\__,_/_.___/
  
Thank you for installing GitLab!
GitLab was unable to detect a valid hostname for your instance.
Please configure a URL for your GitLab instance by setting `external_url`
configuration in /etc/gitlab/gitlab.rb file.
Then, you can start your GitLab instance by running the following command:
  sudo gitlab-ctl reconfigure

For a comprehensive list of configuration options please see the Omnibus GitLab readme
https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md

Help us improve the installation experience, let us know how we did with a 1 minute survey:
https://gitlab.fra1.qualtrics.com/jfe/form/SV_6kVqZANThUQ1bZb?installation=omnibus&release=14-3
[root@gitlab src]# vim /etc/gitlab/gitlab.rb 
##! https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html
external_url 'http://192.168.47.158'  

## Roles for multi-instance GitLab
[root@gitlab src]# gitlab-ctl reconfigure
[root@gitlab src]# gitlab-ctl restart
//View the current gitlab version
[root@gitlab src]# head -1 /opt/gitlab/version-manifest.txt
gitlab-ce 14.3.2
//Crack administrator password


Keywords: Linux

Added by php_wiz_kid on Tue, 12 Oct 2021 10:58:21 +0300