64 Bit Clone App

[Sourn Sanneh]

Herewe'll examine the git clone command in depth. git clone is a Git command line utility which is used to target an existing repository and create a clone, or copy of the target repository. In this page we'll discuss extended configuration options and common use cases of git clone. Some points we'll cover here are:

If a project has already been set up in a central repository, the git clone command is the most common way for users to obtain a development copy. Like git init, cloning is generally a one-time operation. Once a developer has obtained a working copy, all version control operations and collaborations are managed through their local repository.

As a convenience, cloning automatically creates a remote connection called "origin" pointing back to the original repository. This makes it very easy to interact with a central repository. This automatic connection is established by creating Git refs to the remote branch heads under refs/remotes/origin and by initializing remote.origin.url and remote.origin.fetch configuration variables.

An example demonstrating using git clone can be found on the setting up a repository guide. The example below demonstrates how to obtain a local copy of a central repository stored on a server accessible at example.com using the SSH username john:

The first command initializes a new Git repository in the my-project folder on your local machine and populates it with the contents of the central repository. Then, you can cd into the project and start editing files, committing snapshots, and interacting with other repositories. Also note that the .git extension is omitted from the cloned repository. This reflects the non-bare status of the local copy.

The -branch argument lets you specify a specific branch to clone instead of the branch the remote HEAD is pointing to, usually the main branch. In addition you can pass a tag instead of branch for the same effect.

Similar to git init --bare, when the -bare argument is passed to git clone, a copy of the remote repository will be made with an omitted working directory. This means that a repository will be set up with the history of the project that can be pushed and pulled from, but cannot be edited directly. In addition, no remote branches for the repo will be configured with the -bare repository. Like git init --bare, this is used to create a hosted repository that developers will not edit directly.

Passing the --mirror argument implicitly passes the --bare argument as well. This means the behavior of --bare is inherited by --mirror. Resulting in a bare repo with no editable working files. In addition, --mirror will clone all the extended refs of the remote repository, and maintain remote branch tracking configuration. You can then run git remote update on the mirror and it will overwrite all refs from the origin repo. Giving you exact 'mirrored' functionality.

Secure Shell (SSH) is a ubiquitous authenticated network protocol that is commonly configured by default on most servers. Because SSH is an authenticated protocol, you'll need to establish credentials with the hosting server before connecting. ssh://[user@]host.xz[:port]/path/to/repo.git/

Hyper text transfer protocol. The protocol of the web, most commonly used for transferring web page HTML data over the Internet. Git can be configured to communicate over HTTP http[s]://host.xz[:port]/path/to/repo.git/

You can clone a repository from GitHub.com to your local computer, or to a codespace, to make it easier to fix merge conflicts, add or remove files, and push larger commits. When you clone a repository, you copy the repository from GitHub.com to your local machine, or to a remote virtual machine when you create a codespace. For more information about cloning to a codespace, see "Creating a codespace for a repository."

You can clone a repository from GitHub.com to your local computer to make it easier to fix merge conflicts, add or remove files, and push larger commits. When you clone a repository, you copy the repository from GitHub.com to your local machine.

Cloning a repository pulls down a full copy of all the repository data that GitHub.com has at that point in time, including all versions of every file and folder for the project. You can push your changes to the remote repository on GitHub.com, or pull other people's changes from GitHub.com. For more information, see "Using Git".

To clone a repository locally, use the repo clone subcommand. Replace the repository parameter with the repository name. For example, octo-org/octo-repo, monalisa/octo-repo, or octo-repo. If the OWNER/ portion of the OWNER/REPO repository argument is omitted, it defaults to the name of the authenticating user.

To clone your repository using the command line using HTTPS, under "Quick setup", click . To clone the repository using an SSH key, including a certificate issued by your organization's SSH certificate authority, click SSH, then click .

After the clone, a plain git fetch without arguments will updateall the remote-tracking branches, and a git pull withoutarguments will in addition merge the remote master branch into thecurrent master branch, if any (this is untrue when --single-branchis given; see below).

When the repository to clone from is on a local machine,this flag bypasses the normal "Git aware" transportmechanism and clones the repository by making a copy ofHEAD and everything under objects and refs directories.The files under .git/objects/ directory are hardlinkedto save space when possible.

If the repository is specified as a local path (e.g., /path/to/repo),this is the default, and --local is essentially a no-op. If therepository is specified as a URL, then this flag is ignored (and wenever use the local optimizations). Specifying --no-local willoverride the default when /path/to/repo is given, using the regularGit transport instead.

Force the cloning process from a repository on a localfilesystem to copy the files under the .git/objectsdirectory instead of using hardlinks. This may be desirableif you are trying to make a back-up of your repository.

When the repository to clone is on the local machine,instead of using hard links, automatically setup.git/objects/info/alternates to share the objectswith the source repository. The resulting repositorystarts out without any object of its own.

NOTE: this is a possibly dangerous operation; do not useit unless you understand what it does. If you clone yourrepository using this option and then delete branches (or use anyother Git command that makes any existing commit unreferenced) in thesource repository, some objects may become unreferenced (or dangling).These objects may be removed by normal Git operations (such as git commit)which automatically call git maintenance run --auto. (Seegit-maintenance[1].) If these objects are removed and were referencedby the cloned repository, then the cloned repository will become corrupt.

Note that running git repack without the --local option in a repositorycloned with --shared will copy objects from the source repository into a packin the cloned repository, removing the disk space savings of clone --shared.It is safe, however, to run git gc, which uses the --local option bydefault.

If you want to break the dependency of a repository cloned with --shared onits source repository, you can simply run git repack -a to copy allobjects from the source repository into a pack in the cloned repository.

If the reference is on the local machine,automatically setup .git/objects/info/alternates toobtain objects from the reference . Usingan already existing repository as an alternate willrequire fewer objects to be copied from the repositorybeing cloned, reducing network and local storage costs.When using the --reference-if-able, a non existingdirectory is skipped with a warning instead of abortingthe clone.

Progress status is reported on the standard error streamby default when it is attached to a terminal, unless --quietis specified. This flag forces progress status even if thestandard error stream is not directed to a terminal.

Make a bare Git repository. That is, instead ofcreating and placing the administrativefiles in `/.git`, make the itself the $GIT_DIR. This obviously implies the --no-checkoutbecause there is nowhere to check out the working tree.Also the branch heads at the remote are copied directlyto corresponding local branch heads, without mappingthem to refs/remotes/origin/. When this option isused, neither remote-tracking branches nor the relatedconfiguration variables are created.

Use the partial clone feature and request that the server sendsa subset of reachable objects according to a given object filter.When using --filter, the supplied is used forthe partial clone filter. For example, --filter=blob:none willfilter out all blobs (file contents) until needed by Git. Also,--filter=blob:limit= will filter out all blobs of sizeat least . For more details on filter specifications, seethe --filter option in git-rev-list[1].

Also apply the partial clone filter to any submodules in the repository.Requires --filter and --recurse-submodules. This can be turned on bydefault by setting the clone.filterSubmodules config option.

Set up a mirror of the source repository. This implies --bare.Compared to --bare, --mirror not only maps local branches of thesource to local branches of the target, it maps all refs (includingremote-tracking branches, notes etc.) and sets up a refspec configuration suchthat all these refs are overwritten by a git remote update in thetarget repository.

Set a configuration variable in the newly-created repository;this takes effect immediately after the repository isinitialized, but before the remote history is fetched or anyfiles checked out. The is in the same format as expected bygit-config[1] (e.g., core.eol=true). If multiplevalues are given for the same key, each value will be written tothe config file. This makes it safe, for example, to addadditional fetch refspecs to the origin remote.

3a8082e126