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 software development process. It is one of the core ideas of software configuration management.

The most important function of version control is to track file changes. It faithfully records when and who changed what was in the file. Each time a file changes, the version number of the file increases. In addition to recording version changes, another important feature of version control is parallel development. Software development often involves 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. Bug fixes for the most common different versions of software in parallel development can also be effectively solved by branching and merging in version control.

Specifically, in each development task, the development baseline needs to be set first, and the initial development version of each configuration item is determined. During the development process, the developer develops the required target version based on the version of the development baseline. When a requirement change occurs, the scope of the change is determined by evaluating the change, the version of the affected configuration item is modified, and the version tree of the configuration item is extended or branched to form a new target version based on the nature of the change, while no change should be made to the unaffected configuration item. At the same time, you should be able to record and track the impact of changes on versions. You can also rewind to previous versions if necessary. For example, when development requirements or requirements changes are cancelled, the ability to roll back versions to the development baseline version is required. In the quarterly upgrade package unpacking and reorganization process that has occurred in the past, it is essentially to roll back the versions of some configuration items to the development baseline, recombine and merge the 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 should automatically identify the version and ensure uniqueness of version naming. Versions are automatically branched and evolved according to a set usage model during generation. In addition to the version information that is automatically recorded by the system, it is designed to fit into all phases of the software development process. There is also a need to define, collect some metadata to record version-assisted information, standardize development processes, and prepare for future measurements of software processes. Of course, if the selected tools are supported, these auxiliary data will be able to directly calculate the process data, which will facilitate the software process improvement activities. For each baseline control item in the configuration library, access permissions should be set based on its baseline location and state. In general, versions prior to the baseline version should be locked, and if changes need to be made to them, change control processes should be followed.

Common version control tools:

  • gitlab
  • subversion

2. gitlab deployment

# Configure yum source
[root@asuna ~]# cd /etc/yum.repos.d/
[root@asuna yum.repos.d]# rpm -ivh http://mirror.centos.org/centos/7/os/x86_64/Packages/wget-1.14-18.el7_6.1.x86_64.rpm
[root@asuna yum.repos.d]# wget http://mirrors.163.com/.help/CentOS7-Base-163.repo
[root@asuna ~]# sed -i 's/\$releasever/7/g' /etc/yum.repos.d/CentOS7-Base-163.repo
[root@asuna ~]# sed -i 's/^enabled=.*/enabled=1/g' /etc/yum.repos.d/CentOS7-Base-163.repo
[root@asuna ~]# wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo

# Install git
[root@asuna ~]# yum -y install git vim

# Install Dependent Packages
[root@asuna ~]# yum -y install curl openssh-server openssh-clients postfix cronie policycoreutils-python

# Start the postfix service and set the boot self
[root@asuna ~]# systemctl enable --now postfix

# Download rpm package for gitlab
[root@asuna ~]# cd /usr/src/
[root@asuna src]# ls
debug  kernels
[root@asuna src]# wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-11.2.1-ce.0.el7.x86_64.rpm
[root@asuna src]# ls
debug  gitlab-ce-11.2.1-ce.0.el7.x86_64.rpm  kernels

# Install gitlab
[root@asuna src]# rpm -ivh gitlab-ce-11.2.1-ce.0.el7.x86_64.rpm
warning: gitlab-ce-11.2.1-ce.0.el7.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID f27eab47: NOKEY
Preparing...                          ################################# [100%]
Updating / installing...
   1:gitlab-ce-11.2.1-ce.0.el7        ################################# [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

# Modify Profile
[root@asuna ~]# vim /etc/gitlab/gitlab.rb
//Modify the following
.....
external_url 'http://192.168.32.133' 		// Set this as gitlab's server ip address or domain name
.....

# Overload the configuration file and restart gitlab
[root@asuna ~]# gitlab-ctl reconfigure
[root@asuna ~]# gitlab-ctl restart

# View the current gitlab version
[root@asuna ~]# head -1 /opt/gitlab/version-manifest.txt
gitlab-ce 11.2.1
# Crack Administrator Password
[root@localhost ~]# gitlab-rails console production
-------------------------------------------------------------------------------------
 GitLab:       11.2.1 (2d6c1c6)
 GitLab Shell: 8.1.1
 postgresql:   9.6.8
-------------------------------------------------------------------------------------
Loading production environment (Rails 4.2.10)
irb(main):001:0> user = User.where(id:1).first
=> #<User id:1 @root>
irb(main):002:0> user.password = 'sunako111'
=> "sunako111"
irb(main):003:0> user.password_confirmation = 'sunako111'
=> "sunako111"
irb(main):004:0> user.save!
Enqueued ActionMailer::DeliveryJob (Job ID: d8t4a2fc-1g5w-4448-coi9-a3ad8g6h54015) to Sidekiq(mailers) with arguments: "DeviseMailer", "password_change", "deliver_now", gid://gitlab/User/1
=> true
irb(main):005:0> exit


3. Common operations

3.1 Create Users


3.2 Create Group


3.3 Create Project


Posted by jvrothjr on Wed, 25 May 2022 12:11:11 +0300