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
Deploy gitlab
[root@localhost ~]# systemctl disable --now firewalld
[root@localhost ~]# setenforce 0
[root@localhost ~]# cd /usr/src/
[root@localhost src]# ls
debug
[root@localhost src]# wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el8/gitlab-ce-14.3.2-ce.0.el8.x86_64.rpm
--2021-10-12 11:18:33-- https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el8/gitlab-ce-14.3.2-ce.0.el8.x86_64.rpm
Resolving host mirrors.tuna.tsinghua.edu.cn (mirrors.tuna.tsinghua.edu.cn)... 101.6.15.130, 2402:f000:1:400::2
on connection mirrors.tuna.tsinghua.edu.cn (mirrors.tuna.tsinghua.edu.cn)|101.6.15.130|:443... Connected.
Issued HTTP Request, waiting for response... 200 OK
Length: 961561901 (917M) [application/x-redhat-package-manager]
Saving to: "gitlab-ce-14.3.2-ce.0.el8.x86_64.rpm"
gitlab-ce-14.3.2-ce.0.el8.x86_64.rpm 100%[=======================================================================================================>] 917.02M 4.11MB/s Time 4 m 39s
2021-10-12 11:23:13 (3.28 MB/s) - Saved“ gitlab-ce-14.3.2-ce.0.el8.x86_64.rpm" [961561901/961561901])
[root@localhost src]# ls
debug gitlab-ce-14.3.2-ce.0.el8.x86_64.rpm
[root@localhost src]# cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
**SELINUX=disabled**
# SELINUXTYPE= can take one of these three values:
# targeted - Targeted processes are protected,
# minimum - Modification of targeted policy. Only selected processes are protected.
# mls - Multi Level Security protection.
SELINUXTYPE=targeted
[root@localhost src]# yum -y install epel-release vim
[root@localhost src]# yum -y install git curl openssh-server openssh-clients postfix cronie policycoreutils-python-utils
[root@localhost src]# systemctl enable --now postfix
Created symlink /etc/systemd/system/multi-user.target.wants/postfix.service → /usr/lib/systemd/system/postfix.service.
[root@localhost src]# ss -anlt
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 100 [::1]:25 [::]:*
LISTEN 0 128 [::]:22 [::]:*
[root@localhost src]# rpm -ivh gitlab-ce-14.3.2-ce.0.el8.x86_64.rpm
[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: 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@localhost src]# vim /etc/gitlab/gitlab.rb
##! https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html
external_url 'http://192.168.159.3'
## Roles for multi-instance GitLab
[root@localhost src]# gitlab-ctl reconfigure
[root@localhost src]# gitlab-ctl restart
//View the current gitlab version
[root@localhost src]# head -1 /opt/gitlab/version-manifest.txt
gitlab-ce 14.3.2
