Many colleagues like me who have been doing internal development for more than ten years have been doing internal enterprise development. Now they are still using svn. Talking about git with everyone, they all know that svn has not changed since they are used in the project. I believe this It's just a matter of time. Git will be used in the near future, just as ssh was still struts1 and hibernate when I first started. git is closer to the Internet and more convenient. Once an old iron told me that they are a listed company, and the R&D center responsible for managing the overall code is at the svn headquarters. The svn server is down, and he can’t do anything to roll back the version because the previous code is not saved locally. . If it is git, I will tell you that these are not problems. This is the difference between distributed and centralized. In fact, it is understandable that the traditional industry still occupies a larger scope of svn, and the use of git still takes a certain amount of time. It is understandable that you do not want to spend time on tools. Source code: git inside https://github.com/limingios/netFuture
The difference between the principle of GIT and SVN
- SVN
Development history
In February 2000, they contacted Karl Fogel, the author of "Open Source Development with CVS" (Coriolis, 1999), and asked him whether he would be willing to take a role in this new project. Coincidentally, Karl had already discussed a design for a new version control system with his friend Jim Blandy . In 1995, the two established Cyclic Software, a software company that provides commercial support for CVS. Although they operate business services, they still use CVS at work every day. The frustration of using CVS made Jim seriously think about better ways to manage data. Not only did he confirm the name "Subversion", but he also completed the basic design of the Subversion archive. When CollabNetWhen the call came, Karl immediately agreed to join the project, and Jim asked his employer RedHat Software to agree to let him work on the project irregularly. CollabNet hired Karl and Ben Collins-Sussman and began detailed design work in May. With the help of many ideas from Brian Behlendorf, Jason Robbins and Greg Stein from CollabNet (a freelance programmer active in the WebDAV/DeltaV specification process), Subversion quickly attracted the attention of an active developer community . It finds out and welcomes many members who are also frustrated on CVS to do something for this project. Subversion's original design team set a few simple goals. It must be functionally replaceable for CVS, that is, it must be able to do everything that CVS can do. While correcting the most obvious flaws, the same development model must be maintained. Also, Subversion should be very similar to CVS. Any CVS user can get started quickly with a little effort. After 14 months of coding, Subversion began to "self-manage" on August 31, 2001. In other words, developers no longer use CVS to manage Subversion code, but instead manage Subversion itself.
SVN (Subversion) is a centralized management version controller, and Git is a distributed management version controller! This is the core difference between the two. SVN has only a single centralized management server that saves all revisions of files, and people working together connect to this server through the client to retrieve the latest files or submit updates.
The version library is centrally stored on the central server, and when you work, you use your own computer, so you must first obtain the latest version from the central server, and then start to work. Push to the central server. The central server is like a library. If you want to change a book, you must first borrow it from the library, and then go home to change it yourself, and then put it back in the library after the change.
The biggest problem of the centralized version control system is that it must be connected to the Internet to work. If it is okay in the local area network, the bandwidth is large enough, and the speed is fast enough, but if you encounter a slow network speed on the Internet, you may need to submit a 10M file. Five minutes, this is not enough to suffocate people.
If multiple people develop jointly and the svn server hangs up, no one else can submit it. They can only wait for the svn server to get up and cannot complete the collaborative development. For local functions, you can only keep creating branches to distinguish version numbers.
- GIT <English meaning rice bucket, fool>
History development
Many people know that Linus created the open source Linux in 1991. Since then, the Linux system has continued to develop and has become the largest server system software. Although Linus created Linux, the growth of Linux depends on the participation of enthusiastic volunteers from all over the world. So many people write code for Linux all over the world, how is the code of Linux managed? The fact is that before 2002, volunteers from all over the world sent the source code files to Linus via diff, and then Linus himself merged the code manually! You might be thinking, why doesn't Linus put the Linux code in the version control system? Isn't there a free version control system like CVS and SVN? Because Linus is firmly opposed to CVS and SVN, these centralized version control systems are not only slow, but also must be connected to the Internet to be used. There are some commercial version control systems. Although they are easier to use than CVS and SVN, they are paid and not in line with the open source spirit of Linux. However, by 2002, the Linux system had been developed for ten years. The size of the code base made it difficult for Linus to continue to manage it manually. The brothers in the community also expressed strong dissatisfaction with this approach, so Linus chose a business The version control system BitKeeper, BitKeeper's owner BitMover, out of humanitarian spirit, authorized the Linux community to use this version control system for free. The great situation of stability and unity was broken in 2005, because the gathering of great talents in the Linux community inevitably contaminated the social habits of some Liangshan heroes. Andrew, the developer of Samba, tried to crack the BitKeeper protocol (it was not the only one who did this), but was discovered by BitMover (monitoring was done well!), so BitMover became angry and wanted to take back the free use right of the Linux community. Linus can apologize to BitMover and promise to discipline the brothers strictly in the future. Well, this is impossible. The commercial company that developed BitKeeper ended its partnership with the Linux kernel open source community, and they took back the right to use BitKeeper for free. This forces the Linux open source community (especially Linus Torvalds, the creator of Linux) ) Had to learn a lesson, only to develop a version control system of its own will not repeat the same mistakes. They set several goals for the new system:
- speed
- Simple design
- Strong support for non-linear development mode (allowing thousands of parallel development branches)
- Fully distributed
- Ability to efficiently manage super-large-scale projects like the Linux kernel (speed and data volume)
In the end, the actual situation is like this: Linus spent two weeks writing a distributed version control system in C. This is Git! Within a month, the source code of the Linux system was managed by Git! How is a cow defined? You can feel it.
-
git life cycle
- The difference between git and svn
The characteristic of SVN is simple, but it is OK when you need a place to put the code.
The characteristics of Git version control can do anything without relying on the network, and has better support for branching and merging (this should be regarded as the most concerned place for developers).
-
git command collection
Build and use gitlab
Learning the above content is actually enough, but if your position is not a soldier, but a technical manager, you not only need to understand and master the basic commands of the above knowledge, but also need to build the entire private server gitlab environment.
- History gitlab
Initially, the product was named GitLab, which was completely free and open source software distributed under the MIT license.
In July 2013, the product was split into: GitLabCE (Community Edition) and GitLabEE (Enterprise Edition). At that time, the licenses of GitLabCE and GitLabEE were still free and open source software distributed under the MIT license.
In February 2014, GitLab announced the adoption of an open core business model. GitLabEE is set under a proprietary license and contains features that are not present in the CE version.
In July 2015, the company raised another $1.5 million in seed funding. Clients as of 2015 include Alibaba Group, IBM and SpaceX.
In September 2015, GitLab raised US$4 million in Series A funding from Khosla Ventures.
In July 2016, GitLabCEO confirmed the company's open core functions.
In September 2016, GitLab raised US$20 million in Series B funding from AugustCapital and other companies.
Gitlab issued a series of emergency notices on January 31, 2017, stating that a system administrator in the Netherlands deleted a folder containing 310GB of product data due to an operating error, and only 4.5GB was left after canceling the deletion. The operation and maintenance personnel later checked and found that the multiple backup measures claimed and equipped on the website were not working properly or were difficult to use. Gitlab broadcasted the process of recovering data live on YouTube. The website eventually lost the last 6 hours of database data (including questions, merge requests, comments, snippets, etc., excluding code bases).
- Construction of gitlab private server
In this installation of gitlab, I used docker directly, removing many complicated configurations.
If you install according to normal gitlab, you need to configure it (troublesome):
- RAM 2G
- Nginx
- Redis
- Rub
- Progsql
generates a virtual machine from the source code and prepares for work. Vagrant has installed the corresponding docker.
Installing nexus with docker is to avoid complicated operations such as environment variables and user authorization. For how to install different systems of vagrant, please refer to
mac install vgarant: https://idig8.com/2018/07/29/docker-zhongji-07/
window install vgaranthttps://idig8.com/2018/07/ 29/docker-zhongji-08/
| System type | IP address | Node role | CPU | Memory | Hostname |
|---|---|---|---|---|---|
| Centos7 | 192.168.66.100 | git | 2 | 2G | git |
(1). Virtual machine vagrant tells the installation steps
(2). The machine window/mac enables remote login under the root user
su -
# 密码
vagrant
#设置 PasswordAuthentication yes
vi /etc/ssh/sshd_config
sudo systemctl restart sshd
(3). Install gitlab
Run through shell script https://hub.docker.com/r/sonatype/nexus/
mkdir gitlab
cd gitlab
mkdir postgresql
mkdir redis
mkdir gitlab
chown -R 200 data
pwd
ll
vi start.sh
image.png
start.sh User name I set: root password 123456789qwe
#!/bin/bash
cur_dir=`pwd`
docker stop gitlab-postgresql
docker rm gitlab-postgresql
docker stop gitlab-redis
docker rm gitlab-redis
docker stop gitlab
docker rm gitlab
docker run --name gitlab-postgresql -d \
--env 'DB_NAME=gitlabhq_production' \
--env 'DB_USER=gitlab' --env 'DB_PASS=password' \
--env 'DB_EXTENSION=pg_trgm' \
--volume ${cur_dir}/postgresql:/var/lib/postgresql \
sameersbn/postgresql:10
docker run --name gitlab-redis -d \
--volume ${cur_dir}/redis:/var/lib/redis \
sameersbn/redis:4.0.9-1
docker run --name gitlab -d \
--link gitlab-postgresql:postgresql --link gitlab-redis:redisio \
--publish 10022:22 --publish 10080:80 \
--env 'GITLAB_PORT=10080' --env 'GITLAB_SSH_PORT=10022' \
--env 'GITLAB_ROOT_PASSWORD=123456789qwe' \
--env 'GITLAB_SECRETS_DB_KEY_BASE=long-and-random-alpha-numeric-string' \
--env 'GITLAB_SECRETS_SECRET_KEY_BASE=long-and-random-alpha-numeric-string' \
--env 'GITLAB_SECRETS_OTP_KEY_BASE=long-and-random-alpha-numeric-string' \
--volume ${cur_dir}/gitlab:/home/git/data \
sameersbn/gitlab
Run shell script
sh start.sh
It was http://192.168.66.100:10080/ at first, and it was normal after gitlab was initialized.
Administrator: root Password: 123456789qwe
Tips for using git
- .gitignore add ignore files, automatically ignore when adding and submitting
- When developing, if there are 5 developers (A, B, C, D, E), the version will be launched on December 12, 2018, A is the project team leader, and the branch release20181212 is established through the master. The respective branches of the 5 individuals are task_A_relase20181212, task_B_relase20181212, task_C_relase20181212, task_D_relase20181212, task_E_relase20181212. After the respective development is completed, they are merged to release20181212 through the merge method, and A is tested in release20181212. If B (there is an urgent problem), B switches to release20181212 to fix it. After everyone is repaired, release201212 is merged from A to master branch.
- Conflict resolution: Proximity branch, then retreat to the last commit, pull the latest code, then merge with the current branch, and then commit.
PS: Maybe you can’t feel the awesomeness of git. If you are from a relatively small company, it is better to use svn, especially when everyone is not familiar with git. Now it is when the company is relatively large, the branch development of the project Soon, for example, the project I am currently developing has a branch every week. When a new version is submitted on the 4th of the week, there are many old irons in parallel development. Svn is definitely not manageable, but if you use git, There are many functions in gitlab, branch management, and submission tree. It is very powerful. It is very messy and messy during real development. It is all lines. I guess I can't even think about it with svn. It is not only a problem of local submission, not git. The question of whether it is good or not, but whether there is a problem to choose, we choose technology or technology to choose us. If the company uses git, you must use svn, right? In addition, I recommend a relatively awesome git service management tool written by Chinese people: gogs.