Git basics-Get git repository

2.1 git basics-get git repository

Description Source: https://git-scm.com/book/zh/v2/git-base-Get-git-Warehouse

If you can only read a chapter to learn Git, this chapter is your choice. This chapter covers all the basic commands you will use to do all kinds of work with Git. After you have completed this chapter, you should be able to configure and initialize a warehouse (repository), start or stop tracking (track) files, staging (stage), or commit changes. This chapter also shows you how to configure Git to ignore specified file and file patterns, how to quickly and easily undo error actions, how to navigate through the historical versions of your project, and the differences between submissions (commits), How to push (push) to your remote repository and how to pull files from your remote repository. get the Git repository

There are two ways to get the Git project warehouse. The first is to import all files into git under an existing project or directory, and the second is to clone an existing Git repository from a server. Initialize the warehouse in an existing directory

If you plan to use Git to manage existing projects, you only need to enter the project directory and enter:

$ git init

This command creates a subdirectory named. Git, which contains all the necessary files in your initialized git repository, which are the backbone of the Git repository. However, at this point, we just do an initialization operation, and the files in your project are not being tracked. (See Git internals for more information on what files are contained in the. git folder.) )

If you are initializing a Git repository for versioning in a folder that already has files (rather than an empty folder), you should start tracking these files and submitting them. You can use the git add command to track a specified file and then execute a git commit commit:

$ git add *.c
$ git add LICENSE
$ git commit-m ' initial project version '

We will explain the meaning of each instruction one after the other later. Now you've got a Git repository that actually maintains (or tracks) a few files. Cloning an existing warehouse

If you want to get a copy of a git repository that already exists, say you want to contribute to an open source project, you need to use the git clone command. If you are familiar with other VCS systems (such as subversion), be aware that the commands you use are "clone" rather than "checkout". This is an important feature of git that distinguishes it from other version control systems, and Git clones almost all of the data on the GIT repository server, rather than just copying the files needed to complete your work. When you execute the git clone command, each version of each file in a remote Git repository is pulled down by default. In fact, if your server's disk is broken, you can usually use any cloned client to rebuild the repository on the server (although some server-side hook settings may be lost, but all versions of the data are still there, see Building Git on the server).

The command format for the clone repository is git clone [url]. For example, to clone a Git-linked library libgit2, you can use the following command:

$ git clone https://github.com/libgit2/libgit2

This creates a directory named "Libgit2" under the current directory, and in this directory initializes a. Git folder, pulls all the data from the remote repository into the. git folder, and then reads a copy of the latest version of the file from it. If you enter this new Libgit2 folder, you will find that all the project files are already in place and ready to wait for subsequent development and use. If you want to customize the name of the local repository when cloning a remote repository, you can use the following command:

$ git clone https://github.com/libgit2/libgit2 mylibgit

This will perform the same action as the previous command, but the locally created warehouse name becomes Mylibgit.

Git supports a variety of data transfer protocols. The above example uses the https://protocol, but you can also use the GIT://protocol or SSH Transfer Protocol, such as User@server:path/to/repo.git. Building git on the server will explain how all of these protocols are configured on the server side, and the pros and cons of various ways.