Shulou(Shulou.com)05/31 Report--

This article mainly explains the "git init and git clone access to git warehouse methods", the article explains the content is simple and clear, easy to learn and understand, the following please follow the editor's ideas slowly in-depth, together to study and learn "git init and git clone access to git warehouse methods"!

Use git init and git clone to get the git repository

There are usually two ways to get git repositories:

Convert local directories that are not versioned locally to a Git repository

Clone an existing Git repository from another server

1 git init creates a Git repository git init [- Q |-- quiet] [--bare] [--template=] [--separate-git-dir] [--shared [=] [directory] on the local directory

This command creates an empty Git storage database, which basically creates objects,refs/heads,refs/tags, and template files in the .git directory. An initial HEAD file that references the HEAD of the main branch is also created.

If the $GIT_DIR environment variable is specified, the. / .git directory is replaced as the basis for a repository.

If the objects directory is specified through the $GIT_OBJECT_DIRECTORY environment variable, create a sha1 directory under this directory, otherwise it is the default $GIT_DIR/objects directory.

It is safe to run git init in an existing Git repository; it does not overwrite what already exists. The main reason for rerunning git init is to get the newly added template (or if it is the-- separate-git-dir option, move the Git repository to another location).

[- Q,-- quite]

Print only error messages and warnings

[--bare]

Create a naked repository, excluding the .git folder, as follows:

[--template=]

It is used to copy the files in the template folder to the .git storage database at the time of initialization when initializing the Git repository. If not specified, the template under the / usr/share/git-core/templates path is copied by default, which includes the following:

$ls / usr/share/git-core/templates/branches description hooks info

If you specify your default path, the initialized Git storage database is as follows:

The template can be set through-- template= setting, $GIT_TEMPLATE_DIR environment variable setting, init.templateDir configuration setting, and overriding the next level setting in turn.

[--separate-git-dir]

The default git init creates a .git folder under the current directory to store the Git database. This command specifies a path to initialize the Git storage database and creates a .git file locally to link to the specified directory:

You can see that there is only one .git file locally, which describes the exact location of the current warehouse's Git storage database and automatically links to it.

[--shared [=]]

Used to specify the read and write permissions of the created Git storage database, including the same group of users, all users, and so on. If it is not specified, the default is group permission. If you are interested, you can git init-- help to see how this option is used.

[directory]

If this option is specified, the git init command runs in this directory, and the directory is created if it does not exist.

2 git clone cloned the repository from the existing Git storage database to the local directory git clone [--template=] [- l] [- s] [--no-hardlinks] [- Q] [- n] [--bare] [--mirror] [- o] [- u] [--reference] [--dissociate] [--separate-git-dir] [--depth] [--[no-] single-branch] [--no-tags] [--recurse-submodules [=]] [--[no-] shallow-submodules] [--[no-] remote-submodules] [--jobs] [--sparse] [- -]

Clone a repository into the newly created directory, create a remote trace branch for each branch of the cloned Git repository (you can view the trace branch through git branch-- remotes), and create and check out the currently active branch of the clone repository to the local initial branch.

After the clone is complete, a git fetch command with no parameters can update all remote trace branches, and the git pull command with no parameters will merge the remote master branch into the current branch.

This default configuration is achieved by creating a reference to the remote branch header under refs/remotes/origin and initializing the remote.origin.url and remote.origin.fetch configuration variables.

[--template=]

Please see the git init-related options for this option.

[- l,-- local]

Used to clone the Git storage database from the local Git storage repository, this option copies information such as local refs,HEAD to the cloned Git storage database and hard links .git / objects to the local Git repository to save local space.

If the-l option is not specified but [url] is a local path, the behavior of the-l option will still be performed by default, but if the-no-local option is specified to clone the local repository, it will follow the default git clone process:

[- s,-- shared]

When the cloned repository is local, the default is to hard link the .git / objects objects in the local repository to the local clone repository. Using this option will no longer hard link the .git / objects directory, but create an alternates file in the local .git / objects/info directory and describe the original location of objects and share it.

Note: this option is a dangerous option, do not use it unless you understand what it does. If you use this option to clone the local repository and then delete the branches in the source repository, some objects may become unreferenced. These objects may be deleted by git commands (git gc-- atuo may be automatically called inside git commit), resulting in the destruction of the warehouse.

It is also important to note that when running git repack in a repository cloned with the-s option, if the-- local,-l option is not specified, the objects in the source repository will be copied to a package in the clone repository, thus eliminating the sharing effect and space savings brought by the-- shared option. It is safe to run git gc directly because the default-- local,-l option is used.

If you want to break the dependency on shares in the repository specified by the-s option, you can use the git repack-a command to copy all objects from the source repository to a package in the cloned repository.

[--no-hardlinks]

Forcing the contents of .git / objects to be copied in the form of copies instead of hard links when cloning local repositories is useful when backing up Git repositories.

[- Q,-- quite]

Run the command quietly and the progress is not reported to the standard error stream.

[- n,-- no-checkout]

No checkout HEAD operation is performed after the clone is completed:

[--bare]

Create a naked Git repository. That is, not creating a / .git directory or putting administrative files in / .git, but creating an or .git directory for yourself that holds the actual Git database. This option also defaults to-no-checkout, no HEAD is checked out, no remote branches are automatically tracked, and relevant configuration variables are not created.

[--mirror]

Sets the mirror of the source Git repository. Similar to-- bare, contrast-- bare,--mirror not only maps the local branch of the source to the local branch of the target, it also maps all references (including remote tracking branches, notes, etc.) and sets the refspec configuration so that all these references are overwritten by git remote updates in the target repository.

Note:-- bare and-- mirror are used for the server, because the server only needs to save the Git storage database and does not need to actually operate the git command, so when you execute the Git command in the repository created in these two options, you will get the following print:

Fatal: this operation must be run in a work tree

[- o,-- origin]

Origin is used by default to track remote repositories when this option is not used, and after using this option to track remote repositories.

[- b,-- branch]

Do not point the newly created HEAD to the branch that the clone repository HEAD points to, but to the branch.

[- u,-- upload-pack]

When using ssh to access the Git repository to be cloned, it specifies a non-default path for commands run on the other side. This option is mainly used for Git servers and specifies a path for the git used by the server, and so on. It is usually / usr/bin/git-upload-pack, and the program for this path is automatically found when the server's git is running.

[--reference [- if-able]]

If the referenced Git repository is on the local machine, the .git / objects/info/alternates file is automatically set to retrieve the objects from the referenced source repository, and using the existing Git repository as an alternative will require less objects to be copied from the source repository, thereby reducing network and local storage costs. When using-- reference-if-able, a directory that does not exist is skipped and a warning is issued instead of aborting the clone.

[--dissociate]

Borrowing objects objects from the Git repository referenced by-- reference only reduces network transfer and stops borrowing objects from the reference library after cloning by making the necessary local copies of the borrowed objects. You can use this option to stop the new repository from borrowing objects from the same repository when the local clone has borrowed objects from another repository. This option is also used primarily for Git servers.

[--separate-git-dir]

Please see the git init-related options for this option.

[--depth]

To create a shallow clone, the number of commits that need to be cloned is specified, and the number of commits at the top of all branches is obtained and cloned locally. If you also want to simply clone the submodule, you can also pass the-- shallow-submodules option.

[--[no-] single-branch]

As the name implies,-- single-branch will clone only one branch specified in the Git repository, and the other branches in the remote Git repository will not be cloned locally, nor will other remote branches be tracked locally, only a single remote branch.

[--no-tags]

No tags are cloned, and remote..tarOpt=--no-tags is set in the configuration to ensure that subsequent git pull and git fetch do not manipulate tags unless they are explicitly manipulated.

It can be used with-- single-branch to maintain a single branch, which is useful when maintaining only a default branch.

[--recurse-submodules [=]]

After the clone is created, the submodules are initialized and cloned according to the provided submodules, and if not specified, all submodules are initialized and cloned. This option can be given multiple times for those with multiple entries.

Using this option by default is equivalent to running git submodule update-- init-- recursive.

[--[no-] shallow-submodules]

All cloned sub-modules have a shallow clone depth of 1.

[--[no-] remote-submodules]

The status of the branches of all cloned submodules is remotely tracked to update the submodules instead of the SHA1 recorded in the Git database. This is equivalent to passing the-- remote option to git submodule update.

[- j,-- jobs]

The number of submodules taken out at the same time. The default is to configure submodule.fetchJobs.

[--sparse]

Sparse check-out mode, the so-called sparse check-out means that all files are not checked out when the local version library is checked out, only the specified files are checked out from the local version library to the workspace, while other unspecified files are not checked out (even if these files exist in the workspace, their changes are ignored). This feature is not described in detail here.

[-]

It has no practical use, just to separate options from operands so that they can be easily distinguished.

The repository to be cloned may be a remote warehouse, a local warehouse, a https protocol, a ssh protocol, a git protocol, etc.

[]

If this directory is specified, the Git repository will be cloned to this directory.

-v,-- verbose

Lengthy output of clone information.

[- c =,-- config =

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.