Shulou(Shulou.com)06/02 Report--

Foreword:

Gitlab is an open source application developed using Ruby on Rails to implement a self-hosted Git project repository that can be accessed through the Web interface public or private projects Gitlab has similar functions as Github, able to browse source code, manage defects and comments. You can manage the team's access to the warehouse, and it is very easy for him to browse the submitted version and provide a library of file history. He also provides a code snippet collection function that makes it easy to reuse code and make it easier to find it later when needed.

Blog outline:

I. Environmental preparation

2. Install and deploy gitlab

3. Basic operation of remote library

4. Reset the gitlab administrator password

I. Environmental preparation

If it is a test environment, its memory is recommended to be 2GB or above. You can go to Tsinghua Open Source Mirror Station to download the required gitlab version. After installation, nginx will be automatically installed to provide web interface, so port 80 should be avoided.

Install and deploy gitlab1, install gitlabs [root @ git src] # wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-11.9.8-ce.0.el7.x86_64.rpm[root@git ~] # rpm-ivh gitlab-ce-11.9.8-ce.0.el7.x86_64.rpm # install RPM package # because I'm not going to do domain name resolution So you need to modify its configuration file [root@git ~] # vim / etc/gitlab/gitlab.rb external_url 'http://192.168.20.2' # change the original domain name to native IP [root@git ~] # gitlab-ctl reconfigure # reconfigure gitlab, even if you don't modify the configuration file You also need to reconfigure gitlab [root@git ~] # netstat-anpt after installation | grep-w 80 # make sure that nginx is listening on port 80 tcp 00 0.0.0.0 netstat 80 0.0.0.0 netstat * LISTEN 3872/nginx: master 2, configure gitlab

When the client accesses the IP address of the server, you can see the following interface (configure password and log in):

Upload the server public key (the next operation is much the same as on github), and first generate the key pair on the server:

[root@git ~] # ssh-keygen-t rsa-C "916551516@qq.com" # execute the above command to generate a secret key pair and enter all the way, followed by your own mailbox [root@git ~] # cat ~ / .ssh/id_rsa.pub # to view the generated public key and copy its contents ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCVUbmw+PC2plXMviNBA6YKgWx+1419uMPJhJNGeZ8Mi7njBlAyhfzWQsCFamQqU4nwSMWua3oEJZEiT6ZRgLQQyYwZ+DESQCyhAJYdtOgwtRh4XaIgAASzlqZ0hIjhhwi+pD/GjktySiW/UvaiqkkBgfdXCuXlSH7R8T4PoRCpYZ92OwQmMV/blGd/SXLDCaqHlgz1K8As8HFoaFAkrmS+jSio616+w2o8ly2PBbVoZa129BD8SQ81KAs5drGTD2OsKHFx08rS5izSc2MKLjet7+00CXJebwZQLB1LS/TUXwrPAHLQO8ZN8AYCsoIv6coEYRhW93BoBZ8Swetys/KD 916551516@qq.com

Then go back to the web interface:

After adding, it is as follows:

Create a library:

Go back to the server and clone the library you just created:

[root@git ~] # git clone git@192.168.20.2:root/test01.git # Clone [root@git ~] # cd test01/ # enter the cloned library [root@git test01] # ls # the contents in this directory are the same as those just after the web page has created the library. README.md# self-report [root@git test01] # git config-- global user.name "test" [root@git test01] # git config-- global User.email "test@test.com" # upload files to the remote library for testing [root@git test01] # echo "aaaaaaaaa" > test.txt [root@git test01] # git add test.txt [root@git test01] # git commit-m "alter from 192.168.20.2" [root@git test01] # git push origin master # push to the remote library

Refresh the library page of the web interface:

3. Basic operation of remote library

When you clone from a remote repository, git actually automatically corresponds the local master branch to the remote master branch, and the default name of the remote repository is origin.

To view information about the remote library, use the following command:

[root@git test01] # git remote # brief Information origin [root@git test01] # git remote-v # details origin git@192.168.20.2:root/test01.git (fetch) origin git@192.168.20.2:root/test01.git (push)

Push branch:

[root@git test01] # git push origin master # push local master branch [root@git test01] # git push origin dev # push local dev branch. If there is no dev branch at the remote end, it will be created automatically.

Grab the branch:

[root@git test01] # git pull origin dev # grab the remote dev branch as prompted

When we clone from a remote library, by default, we can only see the master branch, which can be confirmed with the git branch command.

Solve the problems easily caused by multi-person cooperation

When our whole team is developing the same branch, if your colleague has modified the content of the branch and pushed it to the remote warehouse before you submit it, and you happen to make changes to the same file and try to push, then the push will fail because the latest data submitted by your colleague conflicts with the data you are trying to submit (your local content is older than the remote warehouse). The solution will be given in the return message that prompts you to push failure. Here we simulate this process.

# enter another directory and clone the remote repository Simulate multiplayer collaboration [root@git test01] # cd / tmp [root@git tmp] # git clone git@192.168.20.2:root/test01.git [root@git test01] # git checkout-b dev # create a branch dev and enter [root@git test01] # echo "aaaaaaaaa" > tmp.txt [root@git test01] # git add tmp.txt [root@git test01] # git commit-m "commmit from / tmp" [root@git test01] # git push origin dev # push the newly modified content to the remote end

Go back to the web interface and refresh, and you can see the newly submitted branch:

The above operation is done under the / tmp directory, so now operate the remote warehouse under the / root directory:

# enter the remote repository under the root directory and create a dev branch, and push the content to the remote repository [root@git test01] # cd / root/test01/ [root@git test01] # git checkout-b dev [root@git test01] # echo "bbbbbbbbbb" > root.txt [root@git test01] # git add root.txt [root@git test01] # git commit-m "commit from / root" [root@git test01] # git push origin dev # at this time The following error To git@192.168.20.2:root/test01.git will be prompted! [rejected] dev-> dev (fetch first) error: unable to push some references to 'git@192.168.20.2:root/test01.git' hint: update is rejected because the remote version library contains submissions that do not yet exist locally. This is usually due to another hint: a version library has pushed the same reference. You may need to merge remote change prompts (such as' git pull') before pushing again. Tip: see the 'Note about fast-forwards' section' in 'git push-help'' for details. # prompt that the remote version library has a submission that is not available in our local version library, so you need to pull the remote version library first. Then submit [root@git test01] # git pull origin dev # follow the prompt to pull the remote dev branch [root@git test01] # ls # the files we submitted in the / tmp directory exist README.md root.txt test.txt tmp.txt [root@git test01] # git push origin dev # and then push the local dev branch to gitlab again to succeed

At this point, the dev branch of the web interface has all the content we submitted under the / tmp directory and / root directory, as follows:

But the master branch, which is still the original file, is as follows:

Now merge the branches of the remote version library As follows: [root@git test01] # git checkout master # switch to master branch [root@git test01] # git merge dev # merge dev branch [root@git test01] # ls # View the content under the merged branch README.md root.txt test.txt tmp.txt# is submitted to the local version library [root@git test01] # git pull # download the remote version library [root@git test01] # git add * [root@git test01] # git commit -m "submit" [master 3717c1c] submit [root@git test01] # git push origin master # push to the remote version library

Now the master branch of the remote version library is as follows:

Now that you have all the contents of the dev branch, let's demonstrate how to delete the dev branch of the remote version library:

[root@git test01] # git branch-d dev # Delete the local dev branch [root@git test01] # git branch-r-d origin/dev # Delete the specified remote branch [root@git test01] # git push origin: dev # submit the deleted branch to the remote version library

At this point, the dev branch in the remote version library is deleted, as follows:

4. Reset the gitlab administrator password [root@git ~] # gitlab-rails console production # to execute the command Only the first command word can be tab-GitLab: 11.9.8 (48528bc) GitLab Shell: 8.7.1 postgresql : 9.6.11-Loading production environment (Rails 5.0.7.1) irb (main): 001irb 0 > user = User.where (id) : 1) .first = > # irb (main): 003irb 0 > user.password='test1234'= > "test1234" irb (main): 004test1234 0 > user.password_confirmation='test1234'= > "test1234" irb (main): 005user.password='test1234'= 0 > user.saveEnqueued ActionMailer::DeliveryJob (Job ID: 17d6f678-3cae-4de2-be59-b19a6d22b9fa) to Sidekiq (mailers) with arguments: "DeviseMailer" "password_change", "deliver_now", # = > trueirb (main): 006 main 0 > true= > trueirb (main): 007 trueirb 0 > exit

At this point, log in again, and you need to log in with the new password test1234.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.