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

Version control is a system that records changes in the contents of one or more files in order to consult specific version revisions in the future. You can version any type of file except the project.

It is a wise choice to adopt version control system (VCS). With it, you can go back to the previous state of a file, or even the entire project to its previous state at a certain point in time, compare the details of the changes in the file, and find out who changed which place in the end. in order to find out the cause of the strange problem, who reported a functional defect and so on. Using a version control system, it doesn't matter if you delete and modify errors in the project, and you can easily revert to the original. But the extra workload is negligible.

Many people are used to copying the entire project directory to save different versions, perhaps renaming it and adding backup time to show the difference. The only advantage of this is that it is simple, but it is easy to make mistakes. Sometimes it will confuse the working directory, accidentally write the wrong file or overwrite the unexpected file. And it's not good for teamwork. In order to solve this problem, many kinds of local version control systems have been developed a long time ago, most of which use some simple database to record the differences of previous updates of files. The picture comes from the official website of Git.

One of the most popular is called RCS, which can still be found in many computer systems today. Even after installing the developer kit on the popular Mac OS X system, you can use the rcs command. It works by saving the patch set on the hard disk (the patch refers to the changes before and after the file revision); by applying all the patches, you can recalculate the contents of each version of the file.

Then there is the question of how to get developers on different systems to work together. Therefore, the centralized version control system (Centralized Version Control Systems, referred to as CVCS) arises at the historic moment. Such as CVS, Subversion (SVN) and Perforce. The centralized version control system is a single centrally managed server that stores revised versions of all files, while people who work together connect to the server through the client to retrieve the latest files or submit updates. Over the years, this has become a standard practice in version control systems. As shown in the figure (source Git official website):

Compared to local version management, centralized version control allows everyone to see to some extent what others in the project are doing. Administrators can easily control the permissions of each developer, and it is far easier to manage a CVCS than to maintain a local database on each client.

It also has the following criticisms:

If a single point of failure goes down, no one can submit updates and work together. If the disk where the central database is located is damaged and not backed up properly, there is no doubt that all data will be lost-including the entire change history of the project, leaving only separate snapshots that people keep on their respective machines.

Why do you need to be connected to the Internet? The centralized version control system warehouse is concentrated on a server, which is also affected by the server network environment.

So distributed version control system (Distributed Version Control System, referred to as DVCS) came out. Git is a typical distributed version control. There are also Mercurial, Bazaar and Darcs.

The client does not just take a snapshot of the latest version of the file, but mirrors the code repository completely. In this way, any server used to work together fails and can be recovered later with any mirrored local repository. Because each clone operation is actually a full backup of the code repository. The picture comes from the official website of Git.

The advantage of distributed version control system is not only that you don't have to connect to the Internet, but we will also see the extremely powerful branch management functions of Git.

In 2002, the Linux kernel open source project enabled a proprietary distributed version control system, BitKeeper, to manage and maintain the code. In 2005, the commercial company that developed BitKeeper ended its partnership with the Linux kernel open source community, and they took back the right of the Linux kernel community to use BitKeeper for free. This forces the Linux open source community (especially Linus Torvalds, the founder of Linux) to develop their own version of the system based on lessons learned when using BitKeeper.

Disadvantages of centralized version control system: the biggest problem with centralized version control system is that it must be connected to the network to work. If it is good in the local area network, the bandwidth is large enough and the speed is fast enough.

There is no "central server" in the distributed version control system at all, and everyone's computer has a complete version library, so that when you work, you don't need to connect to the Internet, because the version library is on your own computer. Since everyone has a complete version library on the computer.

For example, if you change file An on your computer, and your colleague changes file An on his computer, you just need to push your changes to each other and you can see each other's changes.

Compared with the centralized version control system, the distributed version control system is much more secure, because everyone has a complete version library in the computer.

It doesn't matter if someone's computer is broken, just copy one from someone else. If something goes wrong with the central server of the centralized version control system, everyone will not be able to work.

When actually using a distributed version control system, it is rare to push changes to the version library on the computers between the two people, because maybe you two are not in the same local area network and the two computers cannot access each other, or maybe your colleague is sick today and his computer is not turned on at all. Therefore, the distributed version control system usually has a computer that acts as a "central server", but the function of this server is only to facilitate the "exchange" of everyone's changes, and everyone will do the same without it. It's just that it's not convenient to exchange changes.

The storage mode of Git is snapshot technology, while the storage of other version control systems is basically incremental storage. The following pictures are from the Internet.

Git takes a snapshot every time git add adds content to the cache. The snapshot is like taking a picture of the entire directory and files at that time, and the directories and files can be restored to the state where the snapshot was initiated at any time. Git generates snapshots in this way, for files that have not changed, a reference is generated to point to the location of the original file to save space and improve efficiency, and for changed files, the entire file is stored. Each version of git stores a snapshot.

The so-called incremental storage means that except that the first version stores the complete contents of each file, the subsequent version stores the contents of the changes of each file relative to the previous version.

Before the commit operation of Git, there are three states: Untracked files, Changes not staged for commit and Changes to be committed, each of which can be converted to each other at will. Understanding the different situations corresponding to each of these three states can help you to easily and effectively use Git to manage your project.

File status is a very important concept in Git.

In order to explain the concept of file status more clearly, use three pictures on the network.

Initialize a project, that is, put the directory where the project is located under the management of Git. Suppose the project directory is hello_world. After initialization, create a new README.txt file under the directory, and then use "git status" to check the file status. As you can see in the figure, Git friendly marks README.txt as "Untracked files" and prompts you to use "git add...". To include the file in the list to be submitted Follow the prompts, use the "git add README.txt" command, and then use "git status" to view the file status, as shown in the figure: the file README.txt status becomes "Changes to be committed", that is, README.txt generates a snapshot in the staging area, waiting to be committed. As Git hints, the "git rm-- cached README.txt" command allows you to restore the file state to an unstaged state, that is, to return to the "Untracked files" file state. Now, README.txt can be committed to the git directory, but not for the time being. Open README.txt, add some content to it, save it, view it with "git status", and return the information shown in the figure:

As you can see, in addition to the previous "Changes to be committed" status, there is now another "Changes not staged for commit" status, indicating that the file has been modified, but has not been placed in the temporary storage area, that is, no snapshot has been generated. If you do commit now and only submit snapshots of files before modification to the git directory, be sure to remember that only files in the staging area (that is, files with a status of "Changes to be committed") will be committed. As prompted, update the modified file to the staging area with the "git add README.txt" command, or use the "git checkout-- README.txt" command if you want to undo the changes.

Centos/RedHat installation

$yum install curl-devel expat-devel gettext-devel

Openssl-devel zlib-devel

$yum-y install git-core

$git-- version git version 1.7.1

Other versions of the Linux system need to be installed in other ways.

Download it directly on the official website.

The other is to search for GitHub for Windows projects in Github.

The first kind:

Create a new save project folder, execute git init in git bash, and a subdirectory of .git appears under the project folder.

The second kind

Pull an existing git clone [url] from the remote code repository to customize the local repository name git clone [url] dirName

Enter the Git project directory

Cd / myProject

Submit all changes to the staging area

Git add.

Submit changes to the temporary storage area to the local warehouse

Git commit-m "submit description"

Push to remote warehouse

Git push

You can now pull it to JavaPub's remote warehouse.

Ignore file configuration: .gitignore file remove file: git rm filename (remove from staging area and then submit) View file status: git status

Push to remote warehouse: git push origin master push to remote master branch

If there is no remote warehouse, now you want to associate the local warehouse with the remote warehouse, add the following command: git remote add origin, for example, we want to associate a local warehouse with a warehouse created on Github like this git remote add origin https://github.com/Rodert/test.git

You can now push the project to the remote warehouse.

Sometimes we need to query the previous submission history and use the command git log.

Just look at SB.'s submission of records

Git log-author=bob

Sometimes after you submit the code, you find a mistake, and you don't want to keep the record of the last time you submit it, or the description of your last commit message is wrong, you can use the following command: git commit-- amend.

Git commit-amend

Cancel the previous operation, such as git add and git commit.

Git reset filename

Branches are used to insulate feature development. When you create a warehouse, master is the default. Develop on other branches and merge them into the main branch when you are done.

When different versions or system modules are developed in parallel, we usually set up a separate branch for development, and then merge it into the main branch.

Create a new local branch

Git branch test

Switch to the test branch

Git checkout test

You can also merge the above two steps, git checkout-b feature_x.

Switch to the master branch

Git checkout master

Merge branches (there may be conflicts)

Git merge test

Delete the new branch

Git branch-d test

Alternatively, you can push the branch to the remote warehouse git push:

Git push origin test:test

Disclaimer: refer to the source of the Internet, you can leave a message if there is any dispute. Standing on the shoulders of our predecessors, we can see further.

This tutorial is hand-to-hand, committed to the most practical tutorials, do not need any reward, just hope to forward more support.

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.