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

Git Engineering Development practice (1)-- introduction of Git Foundation 1, version Control system 1, version Control system

A version control system (VCS,Version Control Systems) is a system that records changes in the contents of one or more files so that you can consult specific version revisions in the future.

Version control systems are divided into:

A, Local version Control system (LVCS,Local Version Control Systems)

B, centralized version control system (CVCS,Centralized Version Control Systems)

C, distributed version control system (DVCS,Distributed Version Control System)

2. Local version control system

Most of the local version control systems use some kind of simple database to record the differences of previous updates of files. The most popular local version control system is RCS, which works by saving patch sets on the hard disk (patches are changes before and after the revision of the file). By applying all the patches, you can recalculate the contents of each version of the file.

3. Centralized version control system

Centralized version control systems (CVCS,Centralized Version Control Systems) have a single centrally managed server that holds revised versions of all files, while collaborative developers connect to the server through the client to retrieve the latest files or submit updates. Centralized version control systems include CVS, Subversion, Perforce and so on.

The advantage of a centralized version control system: compared to the local version control system, everyone can see to some extent what other people 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.

Disadvantage of centralized version control system: single point of failure of the central server. If the central server goes down, developers cannot submit updates and work together. If the disk of the database of the central server is damaged and there is no backup, it will result in data loss.

4. Distributed version control system

In distributed version control system (DVCS,Distributed Version Control System), the client not only takes the snapshot of the latest version of the file, but also mirrors the code repository completely. therefore, if any server used for cooperation fails, it can be restored by any mirrored local repository. Each clone operation of the distributed version control system is a complete backup of the code repository.

Common distributed version control systems include Git, Mercurial, Darcs, Bazaar and so on.

The characteristic of distributed version control system is distributed, each node has a complete image of the warehouse, and each node can be used as a server or a client. For team collaborative development to merge branches, a node is usually set up as a pseudo-central server

Advantages of a distributed version control system:

A. the submission branch does not need to be connected to the Internet, and the client keeps all history records locally.

B, do not rely on the stability of the server, the risk is dispersed.

Disadvantages of distributed version control systems:

A, synchronous multi-person modification is a little more complicated.

B, lack of rights management system.

Applicable scenarios for distributed version control systems:

A. Development of open source software

B, synchronization needs are not frequent or multi-person collaboration in different places

II. The basis of Git 1. A brief history of Git

The Linux kernel open source project has a wide range of participants, but from 1991 to 2002, Linux kernel developers around the world sent source code files to Linus through diff, and then Linus himself merged the code manually, so most of the Linux kernel maintenance work was spent on submitting patches and saving archives. Although many people in the Linux kernel community have proposed to use centralized version control systems to manage Linux kernel projects, Linus insists on using centralized version control systems that must be connected to the Internet and paid commercial version control systems. By 2002, BitMover authorized the Linux kernel community to use the commercial distributed version control system BitKeeper for free to manage and maintain code.

In 2005, BitMover found that Andrew (Samba developers), active in the Linux kernel community, tried to crack BitKeeper's protocol, so it withdrew its free license to use BitKeeper in the Linux kernel community. However, the tens of millions of lines of code management of the Linux project can not return to the manual merging of the Stone Age, so based on the lessons learned from using BitKeeper and the requirements of the Linux project team, Linus used two weeks to develop the initial version of Git, and a month later Git has been used to manage the source code of the Linux kernel project. Git is currently being developed continuously by other developers in the Linux community.

Most version control systems, such as CVS, Subversion, Perforce, Bazaar, etc., store information in the form of file change lists. The information usually saved is a set of basic files and the differences that each file accumulates over time.

Git treats data as a set of snapshots of small file systems. Each time you submit an update or save the project status in Git, you mainly take a snapshot of all the files at that time and save the index of the snapshot. If the file is not modified, Git no longer restores the file, but only retains a link to the originally stored file.

2. Git installation

Linux distribution:

Fedora:sudo yum install git

Debian:sudo apt-get install git

Windows:

Https://git-scm.com/download/win

Git for Windows (msysGit)

GitHub for Windows

Mac OS:

OSX Git: http://git-scm.com/download/mac

3. Git configuration

Git uses the git config tool to set configuration variables that control the appearance and behavior of Git.

Git config-system

Read and write configuration variables in the / etc/gitconfig file, which contains the common configuration of every user and warehouse on the system, which is valid for all users and warehouses of the current operating system.

Git config-global

Read and write configuration variables in ~ / .gitconfig or ~ / .config / git/config file, which is valid for the current user

Git config-local

Read and write configuration variables in the .git / config file of the warehouse, which is valid for the current warehouse.

The low-level Git configuration information overrides the previous level of configuration information, so the current repository configuration information (.git / config) overrides the configuration information in / etc/gitconfig.

Typically, after installing Git, you need to set up user information, such as the user name and email address. Because each Git commit operation uses Git user information and is written to each commit and cannot be changed.

Git config-- global user.name "username" git config-- global user.email "username@example.com" Git configuration Information View: git config-- listGit configuration Information View: git config Delete a configuration Information: git config-- global unset 4, Git Common terms

Branch: at a point in time, copying a file under version control can independently develop copies without interfering with each other.

Check out (checkout): create a working copy of the warehouse locally.

Commit (commit): write local changes back to the warehouse or merge them into the warehouse.

Conflict: when multiple developers submit changes to the same file at the same time, and the version control system cannot merge them, conflicts occur and need to be handled manually.

Merge: unifies all changes to a file into a file.

Repository: the place where current and historical files under version control are located.

5. Git Workspace

Git has three local work areas: working directory (Work Directory), temporary storage area (Stage/Index), and local warehouse (Repository).

Working directory: working directory / workspace, directory where project code is stored

Temporary storage area: a temporary storage area for temporary storage of changes, essentially a file that holds information about to be submitted to the file list

Local warehouse: securely stores all submitted versions of data, where HEAD points to the latest version placed in the warehouse

Remote repository (Remote Repository): the server that hosts the code

The project directory managed by Directory:Git, including the working directory and Git management space.

Work Directory: working directory, which stores directories and files for version control through Git. It is the directory where developers work.

.git: the directory where Git management information is stored, which is automatically created when the warehouse is initialized.

Index/Stage: the staging area, that is, the update area to be submitted, is essentially a file (.git / index) that holds the list of files to be submitted next time.

Repository: local warehouse, stored in the local version repository.

A HEAD:HEAD pointer that points to a commit of the current branch.

Stash: storage, a working state save stack that saves / restores the temporary state of the working directory.

6. Git workflow

The basic workflow for Git submission is as follows:

A. add, modify and delete files in the working directory.

B. add the files in the working directory that need to be versioned to the temporary storage area.

C. submit the files of the temporary storage area to the local warehouse.

7. .gitignore file filtering

In engineering development, not all files need to be submitted when Git is submitted, such as some automatically generated files. Gitignore can be configured to ignore some files that do not need to be submitted.

Git matches rules from top to bottom for .gitignore configuration files, and if the previous rules match more widely, the latter rules will not take effect.

The collection of .gitignore templates developed by different engineering applications is as follows:

Https://github.com/github/gitignore

The syntax specification for the .gitignore file is as follows:

A, blank lines or lines starting with #, that is, comment lines will be ignored; B, you can add a forward slash / to avoid recursion; you can add a forward slash / to ignore folders, such as build/ that ignores build folder C, can be used! To negate omission; D, * are used to match zero or more characters; E, [] are used to match any character in parentheses, such as [abc], or a hyphen can be added in parentheses, such as [0-9] matches the number from 0 to 9; F,? Used to match a single character

An example of .gitignore is as follows:

# ignore .a files * .a # but negate ignoring lib.a, although .a files have been ignored earlier! lib.a# only ignores TODO files in the current directory But does not include subdir/TODO/TODO# in the subdirectory ignores all files under the build/ folder build/# ignores doc/notes.txt, excluding doc/server/arch.txtdoc/*.txt# ignores all .pdf files in the doc/**/*.pdf under doc/ directory

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.