Existe alguma maneira de recuperar apenas um commit específico de um repositório Git remoto sem cloná-lo no meu PC? A estrutura do repositório remoto é absolutamente igual à minha e, portanto, não haverá conflitos, mas não tenho idéia de como fazer isso e não quero clonar esse enorme repositório.

Eu sou novo no git, existe alguma maneira?

Começando com o Git versão 2.5+ (Q2 2015), é possível buscar um único commit (sem clonar o repositório completo).

Ver commit 68ee628 por Fredrik Medley ( moroten) , 21 de maio de 2015.
^{(mesclado por Junio ​​C Hamano - gitster- no commit a9d3493 , 01 jun 2015)}

Agora você tem uma nova configuração (no lado do servidor)

uploadpack.allowReachableSHA1InWant

Permite upload-packaceitar uma solicitação de busca que solicita um objeto acessível a partir de qualquer dica de referência. No entanto, observe que calcular a acessibilidade de objetos é computacionalmente caro.
O padrão é false.

Se você combinar essa configuração do lado do servidor com um clone superficial ( git fetch --depth=1), poderá solicitar uma única confirmação (consulte t/t5516-fetch-push.sh:

git fetch --depth=1 ../testrepo/.git $SHA1

Você pode usar o git cat-filecomando para verificar se o commit foi buscado:

git cat-file commit $SHA1

" git upload-pack" que serve " git fetch" pode ser dito para servir confirmações que não estão na ponta de qualquer referência, desde que sejam alcançáveis ​​a partir de uma referência, com a uploadpack.allowReachableSHA1InWant variável de configuração.

A documentação completa é:

upload-pack: permitir opcionalmente buscar sha1 acessível

Com a uploadpack.allowReachableSHA1InWantopção de configuração definida no lado do servidor, " git fetch" pode fazer uma solicitação com uma linha "querer" que nomeie um objeto que não foi anunciado (provavelmente obtido fora da banda ou de um ponteiro de submódulo).
Apenas objetos alcançáveis ​​a partir das dicas de ramificação, ou seja, a união de ramificações anunciadas e ramificações ocultas por transfer.hideRefs, serão processados.
Observe que há um custo associado de ter que retornar ao histórico para verificar a acessibilidade.

Esse recurso pode ser usado ao obter o conteúdo de um determinado commit, pelo qual o sha1 é conhecido, sem a necessidade de clonar todo o repositório, especialmente se uma busca superficial for usada .

Casos úteis são, por exemplo,

• repositórios contendo arquivos grandes no histórico,
• buscando apenas os dados necessários para uma finalização do submódulo,
• ao compartilhar um sha1 sem dizer a qual ramo exato ele pertence e no Gerrit, se você pensa em termos de confirmação em vez de alterar números.
  (O caso Gerrit já foi resolvido, allowTipSHA1InWantpois todas as alterações da Gerrit têm uma ref.)

O Git 2.6 (terceiro trimestre de 2015) melhorará esse modelo.
Consulte commit 2bc31d1 , commit cc118a6 (28 de julho de 2015) por Jeff King ( peff) .
^{(Mesclado por Junio ​​C Hamano - gitster- no commit 824a0be , 19 de agosto de 2015)}

refs: suporte negativo transfer.hideRefs

Se você ocultar uma hierarquia de referências usando a transfer.hideRefsconfiguração, não há como substituí-la posteriormente para "ocultá-la".
Este patch implementa uma ocultação "negativa" que faz com que as correspondências sejam imediatamente marcadas como não ocultas, mesmo que outra correspondência oculte.
Nós tomamos o cuidado de aplicar as correspondências na ordem inversa de como elas nos são alimentadas pelo mecanismo de configuração, pois isso permite que o nosso "último vencedor" usual trabalhe com precedência de configuração (e as entradas .git/config, por exemplo, serão substituídas /etc/gitconfig).

Então agora você pode fazer:

git config --system transfer.hideRefs refs/secret
git config transfer.hideRefs '!refs/secret/not-so-secret'

ocultar refs/secretem todos os repositórios, exceto um bit público em um repositório específico.

O Git 2.7 (Nov / Dez 2015) será aprimorado novamente:

Consulte commit 948bfa2 , commit 00b293e (05 de novembro de 2015), commit 78a766a , commit 92cab49 , commit 92cab49 , commit 92cab49 (03 nov 2015), commit 00b293e , commit 00b293e (05 nov 2015) e commit 92cab49 , commit 92cab49 , commit 92cab49 , commit 92cab49 (03 de novembro de 2015) por Lukas Fleischer ( lfos) .
Ajudado por: Eric Sunshine ( sunshineco) .
^{(Mesclado por Jeff King - peff- no commit dbba85e , 20 de novembro de 2015)}

config.txt: documentar a semântica hideRefscom namespaces

No momento, não há uma definição clara de como transfer.hideRefsdeve se comportar quando um espaço para nome é definido.
Explique que os hideRefsprefixos correspondem aos nomes separados nesse caso. É assim que os hideRefspadrões são atualmente tratados no pacote de recebimento.

hideRefs: adicione suporte para referências completas correspondentes

Além de combinar refs removidos, agora é possível adicionar hideRefspadrões com os quais o ref completo (sem strip) é comparado.
Para distinguir entre correspondências despojadas e completas, esses novos padrões devem ser prefixados com um circunflexo ( ^).

Daí a nova documentação :

transfer.hideRefs:

Se um espaço para nome estiver em uso, o prefixo do espaço para nome será retirado de cada referência antes de corresponder aos transfer.hiderefspadrões.
Por exemplo, se refs/heads/masterfor especificado no transfer.hideRefseo namespace atual é foo, em seguida, refs/namespaces/foo/refs/heads/master é omitida a partir dos anúncios, mas refs/heads/mastere refs/namespaces/bar/refs/heads/masterainda são anunciados como chamadas linhas "têm".
Para corresponder aos árbitros antes da remoção, adicione um ^na frente do nome do árbitro. Se você combinar !e ^, !deve ser especificado primeiro.

R .. menciona nos comentários a configuração uploadpack.allowAnySHA1InWant, que permite upload-packaceitar uma fetchsolicitação que solicita qualquer objeto. (O padrão é false).

Veja commit f8edeaa (novembro de 2016, Git v2.11.1) por David "novalis" Turner ( novalis) :

upload-pack: opcionalmente, permite buscar qualquer sha1

Parece um pouco tolo fazer uma verificação de acessibilidade no caso em que confiamos que o usuário acesse absolutamente tudo no repositório.

Além disso, é atrevido em um sistema distribuído - talvez um servidor anuncie uma ref, mas outro desde então teve um empurrão forçado nessa ref, e talvez as duas solicitações HTTP acabem direcionadas para esses servidores diferentes.

Você clona apenas uma vez; portanto, se você já possui um clone do repositório remoto, extrair dele não fará o download de tudo novamente. Apenas indique qual ramo você deseja obter ou busque as alterações e faça o checkout do commit que deseja.

Buscar em um novo repositório é muito barato em largura de banda, pois só fará o download das alterações que você não possui. Pense em termos de Git fazendo a coisa certa, com carga mínima.

O Git armazena tudo na .gitpasta. Um commit não pode ser buscado e armazenado isoladamente, ele precisa de todos os seus ancestrais. Eles estão inter-relacionados .

Para reduzir o tamanho do download, você pode solicitar ao git que busque apenas objetos relacionados a uma ramificação ou confirmação específica:

git fetch origin refs/heads/branch:refs/remotes/origin/branch

Isso fará o download apenas de confirmações contidas na ramificação remota branch (e apenas as que você sente falta) e as armazenará origin/branch. Você pode mesclar ou finalizar a compra.

Você também pode especificar apenas uma confirmação SHA1:

git fetch origin 96de5297df870:refs/remotes/origin/foo-commit

Isso fará o download apenas do commit do SHA-1 96de5297df870 especificado (e de seus ancestrais que você sente falta) e o armazenará como filial remota (não existente) origin/foo-commit.

Eu fiz um puxão no meu repositório git:

git pull --rebase <repo> <branch>

Permitindo que o git puxasse todo o código da ramificação e depois fui redefinir o commit que me interessava.

git reset --hard <commit-hash>

Espero que isto ajude.

Você pode simplesmente buscar um único commit de um repositório remoto com

git fetch <repo> <commit>

Onde,

• <repo>pode ser um nome de repositório remoto (por exemplo origin) ou até mesmo um URL de repositório remoto (por exemplo https://git.foo.com/myrepo.git)
• <commit> pode ser o commit do SHA1

por exemplo

git fetch https://git.foo.com/myrepo.git 0a071603d87e0b89738599c160583a19a6d95545

depois de buscar o commit (e os ancestrais ausentes), você pode simplesmente fazer checkout com

git checkout FETCH_HEAD

Observe que isso o levará ao estado "cabeça desanexada".

Você pode simplesmente buscar o repositório remoto com:

git fetch <repo>

Onde,

• <repo>pode ser um nome de repositório remoto (por exemplo origin) ou até mesmo um URL de repositório remoto (por exemplo https://git.foo.com/myrepo.git)

por exemplo:

git fetch https://git.foo.com/myrepo.git 

depois de buscar os repositórios, você pode mesclar os commits que você deseja (já que a pergunta é sobre recuperar um commit, em vez disso, você pode usar cherry-pick para escolher apenas um commit):

git merge <commit>

• <commit> pode ser o commit do SHA1

por exemplo:

git cherry-pick 0a071603d87e0b89738599c160583a19a6d95545

ou

git merge 0a071603d87e0b89738599c160583a19a6d95545

se é a confirmação mais recente que você deseja mesclar, você também pode usar a variável FETCH_HEAD:

git cherry-pick (or merge) FETCH_HEAD

Isso funciona melhor:

git fetch origin specific_commit
git checkout -b temp FETCH_HEAD

nomeie "temp" o que quiser ... esse ramo pode ficar órfão

Finalmente, encontrei uma maneira de clonar commit específico usando git cherry-pick . Supondo que você não tenha nenhum repositório no local e esteja obtendo commit específico do remoto,

1) crie um repositório vazio no local e git init

2) git remote add origin " url-de-repository "

3) origem do git fetch [isso não moverá seus arquivos para o espaço de trabalho local, a menos que você mescle]

4) git cherry-pick " Digite-comprimir-hash-que-você precisa "

Feito. Dessa forma, você terá apenas os arquivos desse commit específico no seu local.

Enter-long-commit-hash:

Você pode obter isso usando -> git log --pretty = oneline

Eu acho que 'git ls-remote' ( http://git-scm.com/docs/git-ls-remote ) deve fazer o que você deseja. Sem força buscar ou puxar.

Se o commit solicitado estiver nas solicitações pull do repositório remoto, você poderá obtê-lo pelo seu ID:

# Add the remote repo path, let's call it 'upstream':
git remote add upstream https://github.com/repo/project.git

# checkout the pull ID, for example ID '60':
git fetch upstream pull/60/head && git checkout FETCH_HEAD