Как

How to clone all branches git

21.08.202221.08.2022 admin 0 Comments how, how to made, как, как сделать, как создать, совими руками

How to clone all branches git

How to clone a git repo with all branches and tags from refs/remotes?

I have a local git repo that I created from an svn repo:

I then created a backup remote and pushed everything to it:

Now, when I try to clone from my backup, it is missing all svn tags and branches.

How do I clone the repo with all tags and branches?

The only way I have found is to mirror the repo:

This creates a local mybackup.git directory, which knows about all tags/branches (I can use tab completion to get the entire list) but it is not a valid usable repo:

There must be command line option to truly clone the repo with all branches/tags.

2 Answers 2

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

There, you have a full working directory.

After a lot of searching, I finally found an answer.

My main reason in doing this is to get my SVN tags/branches copied over rather than only having master pointing to SVN trunk and without having to parse the entire SVN history (very slow for projects with a lot of history, tags and branches). So to copy over my SVN info:

To speed this process up, I created a shell script:

In order to create such a backup from an existing git SVN repo:

git clone

Purpose: repo-to-repo collaboration development copy

Repo-to-repo collaboration

It’s important to understand that Git’s idea of a “working copy” is very different from the working copy you get by checking out code from an SVN repository. Unlike SVN, Git makes no distinction between the working copy and the central repository—they’re all full-fledged Git repositories.

This makes collaborating with Git fundamentally different than with SVN. Whereas SVN depends on the relationship between the central repository and the working copy, Git’s collaboration model is based on repository-to-repository interaction. Instead of checking a working copy into SVN’s central repository, you push or pull commits from one repository to another.

Of course, there’s nothing stopping you from giving certain Git repos special meaning. For example, by simply designating one Git repo as the “central” repository, it’s possible to replicate a centralized workflow using Git. The point is, this is accomplished through conventions rather than being hardwired into the VCS itself.

Usage

git clone is primarily used to point to an existing repo and make a clone or copy of that repo at in a new directory, at another location. The original repository can be located on the local filesystem or on remote machine accessible supported protocols. The git clone command copies an existing Git repository. This is sort of like SVN checkout, except the “working copy” is a full-fledged Git repository—it has its own history, manages its own files, and is a completely isolated environment from the original 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:

Cloning to a specific folder

Clone the repository located at ＜repo＞ into the folder called

＜directory＞! on the local machine.

Cloning a specific tag

Shallow clone

Clone the repository located at ＜repo＞ and only clone the
history of commits specified by the option depth=1. In this example a clone of ＜repo＞ is made and only the most recent commit is included in the new cloned Repo. Shallow cloning is most useful when working with repos that have an extensive commit history. An extensive commit history may cause scaling problems such as disk space usage limits and long wait times when cloning. A Shallow clone can help alleviate these scaling issues.

Configuration options

This above example would clone only the new_feature branch from the remote Git repository. This is purely a convenience utility to save you time from downloading the HEAD ref of the repository and then having to additionally fetch the ref you need.

Other configuration options

For a comprehensive list of other git clone options visit the official Git documentation. In this document, we’ll touch on some other common options.

Clones the repo at ＜repo location＞ and applies the template from ＜template directory＞ to the newly created local branch. A thorough refrence on Git templates can be found on our git init page.

Git URLs

Git has its own URL syntax which is used to pass remote repository locations to Git commands. Because git clone is most commonly used on remote repositories we will examine Git URL syntax here.

Git URL protocols

-SSH

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/

— GIT

A protocol unique to git. Git comes with a daemon that runs on port (9418). The protocol is similar to SSH however it has NO AUTHENTICATION. git://host.xz[:port]/path/to/repo.git/

— HTTP

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/

Summary

1. git clone is used to create a copy of a target repo

2. The target repo can be local or remote

3. Git supports a few network protocols to connect to remote repos

4. There are many different configuration options available that change the content of the clone

For further, deeper reference on git clone functionality, consult the official Git documentation. We also cover practical examples of git clone in our setting up a repository guide.

How to clone all branches git

Check your version of git by running

SYNOPSIS

DESCRIPTION

After the clone, a plain git fetch without arguments will update all the remote-tracking branches, and a git pull without arguments will in addition merge the remote master branch into the current master branch, if any (this is untrue when «—single-branch» is given; see below).

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

OPTIONS

Operate quietly. Progress is not reported to the standard error stream.

Run verbosely. Does not affect the reporting of progress status to the standard error stream.

No checkout of HEAD is performed after the clone is complete.

Fail if the source repository is a shallow repository. The clone.rejectShallow configuration variable can be used to specify the default.

Employ a sparse-checkout, with only files in the toplevel directory initially being present. The git-sparse-checkout[1] command can be used to grow the working directory as needed.

When given, and the repository to clone from is accessed via ssh, this specifies a non-default path for the command run on the other end.

Specify the directory from which templates will be used; (See the «TEMPLATE DIRECTORY» section of git-init[1].)

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

Create a shallow clone with a history after the specified time.

Create a shallow clone with a history, excluding commits reachable from a specified remote branch or tag. This option can be specified multiple times.

After the clone is created, initialize and clone submodules within based on the provided pathspec. If no pathspec is provided, all submodules are initialized and cloned. This option can be given multiple times for pathspecs consisting of multiple entries. The resulting clone has submodule.active set to the provided pathspec, or «.» (meaning all submodules) if no pathspec is provided.

All submodules which are cloned will be shallow with a depth of 1.

Instead of placing the cloned repository where it is supposed to be, place the cloned repository at the specified directory, then make a filesystem-agnostic Git symbolic link to there. The result is Git repository can be separated from working tree.

The number of submodules fetched at the same time. Defaults to the submodule.fetchJobs option.

The (possibly remote) repository to clone from. See the GIT URLS section below for more information on specifying repositories.

The name of a new directory to clone into. The «humanish» part of the source repository is used if no directory is explicitly given ( repo for /path/to/repo.git and foo for host.xz:foo/.git ). Cloning into an existing directory is only allowed if the directory is empty.

GIT URLS

In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent.

Git supports ssh, git, http, and https protocols (in addition, ftp, and ftps can be used for fetching, but this is inefficient and deprecated; do not use it).

The native transport (i.e. git:// URL) does no authentication and should be used with caution on unsecured networks.

The following syntaxes may be used with them: