Perguntas[git](coding)

Tenho um fluxo de trabalho em que as ramificações locais acabam com nomes que eu realmente não quero que fiquem visíveis no repositório remoto. Gostaria de definir o nome upstream ao criar a ramificação local , para não precisar me lembrar de fazer isso ao usar git push.

Analisei muitas perguntas/respostas aqui e vi duas recomendações para definir nomes de ramificações upstream:

1. Usargit config --local remote.origin.push LOCAL_BRANCH:REMOTE_BRANCH
2. Usargit branch --set-upstream-to REMOTE_BRANCH
3. Usar git push -uougit push origin LOCAL_BRANCH:REMOTE_BRANCH

O primeiro "mais ou menos funciona" porque, se eu enviar o branch local, ele quer enviar para o branch remoto esperado, mas também redefine qualquer valor existente naquela entrada de configuração, o que eu não quero.

O segundo não funciona quando o branch remoto não existe, me dando:

fatal: the requested upstream branch 'foobar' does not exist
hint: 
hint: If you are planning on basing your work on an upstream
hint: branch that already exists at the remote, you may need to
hint: run "git fetch" to retrieve it.
hint: 
hint: If you are planning to push out a new local branch that
hint: will track its remote counterpart, you may want to use
hint: "git push -u" to set the upstream config as you push.
hint: Disable this message with "git config advice.setUpstreamFailure false"

E o terceiro obviamente não é o que estou procurando, porque quero que isso ocorra no momento da criação da ramificação.

Tentei enviar para um novo controle remoto (com nome diferente) e configurei para que as seguintes entradas aparecessem na configuração local:

branch.foo.remote=origin
branch.foo.upstream=foobar
branch.foo.merge=refs/heads/foobar

Mas, se eu removê-los e recriá-los manualmente com um nome diferente, quando eu os envio (sem -u), ele só quer usar o nome do branch local.

Então estou começando a achar que não existe uma maneira realmente boa de fazer isso.

Só para reiterar, o que eu quero é:

Uma maneira de configurar uma nova ramificação local para ter um nome de ramificação remota diferente quando for enviada pela primeira vez, sem precisar definir explicitamente esse nome quando for enviada pela primeira vez

Isso é possível?

EDIT: Acontece que, embora a resposta fornecida funcione para a linha de comando do git, ela não parece funcionar no IntelliJ (talvez o IntelliJ armazene em cache as informações de configuração do git?).

Tenho dois clones locais do mesmo repositório remoto ( urlA):

1. espelho/ – criado com

   git clone --mirror urlA mirror
   

2. dirB/ – criado com

   git clone --reference-if-able ../mirror urlA dirB
   

No dirB , quando executo:

git fetch
git push

será espelhado/ atualizado por qualquer um dos comandos?

Pelo que entendi, isso --reference-if-ableapenas acelera os downloads de objetos reutilizando objetos do repositório de referência, e não transforma a referência em um controle remoto real que recebe fetchou push. No entanto, encontrei em outro lugar um comentário sugerindo que isso poderia propagar comandos.

Pergunta:
Alguma vez houve --reference[-if-able]um gatilho fetchou pushno repositório de referência? Se não, como posso configurar o Git para que um único git pushcomando ou git fetchde dirB também atualize meu clone do espelho local?

Escrevi um utilitário que coleta "métricas" antes e depois (resultados da execução de testes de backend e frontend) e armazeno os resultados em uma subpasta com o nome da ramificação na qual os testes foram executados (essa subpasta existe em uma pasta específica definida pelo usuário e não na pasta "projeto" — fica a critério do usuário decidir quando limpar as subpastas antigas). Tudo o que o utilitário faz é relativo ao Diretório de Trabalho Atual, que se presume ser a pasta raiz ou "projeto" na qual o repositório git que está sendo testado está armazenado localmente.

O utilitário solicita ao git o nome da ramificação atual no CWD. Eu uso "git name-rev --name-only HEAD" para obter esse nome. Desde que eu tenha feito commit de algo pelo menos uma vez nessa ramificação, funciona perfeitamente. No entanto, o caso de uso é que você executará o utilitário ao cortar uma nova ramificação e, em seguida, executá-lo-á novamente quando estiver pronto para uma solicitação de mesclagem; as métricas de antes e depois são então copiadas para o modelo MR que usamos. No entanto, quando uma ramificação é cortada pela primeira vez, o comando acima retorna o nome da ramificação da qual cortei, não o nome real da nova ramificação. Além de executar "git status" e analisar a saída, existe alguma maneira de obter o nome correto da ramificação de forma confiável com algum outro comando git?

Às vezes, eu clono um repositório no GitHub usando o botão "Abrir com o GitHub Desktop", conforme documentado aqui no GitHub . No entanto, essa funcionalidade sempre clona, ​​por padrão, usando https em vez de ssh.

Então, toda vez que clono algo, preciso alterar manualmente a URL. Existe alguma maneira de informar ao GitHub que nunca quero clonar com https e sempre quero clonar com ssh?

Criei uma nova ramificação para mexer no código sem bagunçar a ramificação principal em que estava trabalhando. Acabou não dando resultado, então voltei a trabalhar na ramificação pai sem implementar nenhuma das alterações. Há um único commit feito na nova ramificação, mas eu o quero fora do histórico de commits!

O commit foi enviado para um repositório remoto, então há um ponteiro de origem nele. Não tenho certeza se isso tem alguma coisa a ver. Socorro!

git rebase -i <commit id>Não fez nada por mim, apenas me levou a modificar as ramificações mais recentes. Tentei executá-lo enquanto estava na ramificação em que o commit foi feito e na ramificação pai.

Este é um exemplo de estrutura de diretório

ParentRepo/
    .git/
    parent_file
    ChildRepo/
        .git/
        child_file
        child_untracked

Quero que o ParentRepo rastreie as alterações de todos os arquivos sob si mesmo (rastrear parent_file, child_file, child_untrackedmas não rastrear ChildRepo/.git) como se ChildReponão fosse um repositório git, mas preciso mantê-lo ChildRepocomo um repositório git

Existem três requisitos rígidos

• O conteúdo do ChildRepo deve ser rastreado diretamente no ParentRepo e não como referência a um commit do ChildRepo. Por exemplo, devo ser capaz de excluir ChildRepo/e recuperar seu conteúdo a qualquer momento no histórico do ParentRepo usando apenas informações do ParentRepo/.git/diretório, sem usar uma cópia externa do ChildRepo de outro servidor ou de um backup. Adicionar o ChildRepo como um submódulo do ParentRepo é insuficiente, pois, se todo o diretório do ChildRepo for excluído, não há como recuperá-lo usando apenas as informações do ParentRepo. A recuperação ChildRepo/.git/não é necessária.
• O ChildRepo deve permanecer um repositório git que tenha seu próprio histórico de desenvolvimento independente do ParentRepo; não podemos excluir a ChildRepo/.git/pasta
• O ParentRepo deve ser capaz de rastrear alterações que nunca são confirmadas no ChildRepo, por exemplo, child_untrackedpodem nunca entrar no histórico do ChildRepo, mas ainda deve ser possível rastreá-las no ParentRepo

Atualmente, o git trata qualquer diretório com um subdiretório .git/ como um repositório git e preciso ignorar esse comportamento

Estas são as razões para os estranhos requisitos conflitantes

• Uma compilação completa de qualquer versão anterior deve ser possível, mas não há garantia de que a cópia upstream do ChildRepo esteja disponível no futuro. Se o ChildRepo for removido do ParentRepo no futuro, é possível interromper uma compilação anterior que dependa do ChildRepo, pois o conteúdo não é armazenado no ParentRepo e o upstream foi excluído permanentemente. Quanto ao motivo pelo qual o ChildRepo não pode ser copiado separadamente, não há como garantir que uma cópia do ChildRepo seja armazenada junto com o ParentRepo por todo o período futuro do ParentRepo, e também não há garantia de que a cópia do ChildRepo contenha todos os commits referenciados pelo ParentRepo se, por exemplo, o histórico do ChildRepo tiver sido reescrito. A preservação de compilações anteriores é o objetivo principal e é de extrema importância aqui; portanto, o repositório pai deve rastrear o conteúdo de todas as dependências, não apenas as versões.
• O ChildRepo deve rastrear seu próprio histórico de desenvolvimento independente do ParentRepo
• Nem sempre faz sentido, nem sempre é possível fazer um commit no ChildRepo no momento exato em que preciso fazer um commit no ParentRepo

Gostaria de ter linhas no meu .gitignorearquivo que ignorassem um diretório inteiro e seus subdiretórios, além de quaisquer arquivos (e suas estruturas de pastas) que terminam em .pdf

No momento eu uso;

outputs/*
!outputs/**/*.pdf

e isso exclui o diretório de saídas e então parece incluir uma seleção aleatória de subdiretórios e .csv's e .png's.

A estrutura de pastas não é fixa para os arquivos PDF (pode ter 1 ou 8 subdiretórios), mas eu quero manter os arquivos .pdf apenas nessa outputs/pasta. Para ser sincero, achei que o que eu tinha era o certo!

Estou escrevendo um arquivo em lote do Windows para simplificar a geração de documentação. Sou relativamente novo nisso. Parte disso envolve consultar meu repositório Git para encontrar as duas tags de lançamento mais recentes. Assim que tiver essas tags, a intenção é usar o comando git log e gravar a saída em um arquivo de texto em um diretório diferente.

Posso gravar a saída de um log do git em um arquivo de texto se eu escrever o comando git log com os nomes das tags como constantes. No entanto, quando uso as variáveis ​​que têm os nomes das tags armazenados, só consigo obter a saída visível na janela cmd, e os arquivos de texto produzidos ficam em branco.

A execução com tags conhecidas, conforme abaixo, produzirá tanto na janela de comando quanto em um arquivo de texto

git log --format="%%s" OLD_RELEASE..NEW_RELEASE > "C:\Documentation\Commits.txt"

A saída na janela de comando e o arquivo de texto de saída são mostrados abaixo e estão alinhados com os comentários no git (comentários ruins, eu sei, mas tentei manter essas informações deliberadamente vagas)

V3.1.2.0 19 Sept
V3.1.1.2 6 August
V3.1.1.1 16 July 
V3.1.1.1 15 July 
V3.1.2.0 14 July 
535 indicator added to setup screen
fault 4 severity level reduced from non-threatening

Entretanto, se eu primeiro tiver pesquisado as tags para determinar os dois nomes de tags e defini-los como a variável "OldTag" e "NewTag" e, em seguida, usar o mesmo comando, porém formatado como abaixo, vejo o comando idêntico correto na janela de comando e a lista de mensagens de confirmação, mas o arquivo de texto de saída está em branco.

git log --format="%%s" %OldTag%..%NewTag% > "C:\Documentation\Commits.txt" 

Descobri que executar um comando híbrido, onde a segunda variável é usada como um valor fixo, parece funcionar com a saída sendo gravada no arquivo de texto. Portanto, parece que o uso da segunda variável está impedindo a execução do comando de saída.

git log --format="%%s" %OldTag%..NEW_RELEASE > "C:\Documentation\Commits.txt"

Já li muitas explicações sobre o que git diffacontece entre dois commits e ainda estou completamente perplexo com o resultado que estou obtendo. Acredito que o que estou vendo seja o "formato combinado", considerado o formato "padrão", mas, se for esse o caso, não sei quais outros formatos estão disponíveis.

Exemplo:

>git diff af738ab0..bbbec26d > gitdiff_2025-04-09B.diff

Geralmente recebo esse tipo de coisa:

...
+diff --git a/src/core/history_table_view.py b/src/core/history_table_view.py
+index 5b18236..05b262a 100644
+--- a/src/core/history_table_view.py
++++ b/src/core/history_table_view.py
+@@ -14,188 +14,279 @@ class HistoryTableView(QtWidgets.QTableView):
+     @thread_check(True)
+     def __init__(self, *args):
+         super().__init__(*args)
+-        self.setObjectName('history table')
+-        self.setSelectionMode(QtWidgets.QAbstractItemView.SingleSelection)
+-        self.horizontalHeader().setStretchLastSection(True)
+-        self.horizontalHeader().hide()
+-        self.verticalHeader().hide()
+-        self.setModel(HistoryTableModel(self))
...

... nesta parte da saída, ele está comparando o arquivo history_table_view.py no primeiro commit com o mesmo arquivo no segundo commit.

Todas as linhas acima estão presentes em ambos os arquivos. Então, por que essa linha pode

+     def __init__(self, *args):    

comece com um simples "+", enquanto esta linha

+-        self.setObjectName('history table')

começa com "+-"? O que isso significa? Como eu disse, ambas as linhas estão presentes em ambas as versões deste arquivo. Eu esperaria, git diffa princípio, que nenhuma dessas linhas fosse exibida (embora haja algumas diferenças em termos de linhas vazias entre as linhas com texto).

Em segundo lugar, quando assisto a uma introdução simples git diff, como esta , o apresentador faz git diffdois commits, aos 4:40 do vídeo vemos a saída... mas no caso dele ele NÃO está vendo símbolos duplos no início das linhas, mas sim simples "+" ou "-", ou seja, até onde eu entendo, o que se poderia esperar de um diffcomando BASH feito entre dois arquivos. ESSE FORMATO SIMPLES É TUDO O QUE EU QUERO.

Suspeito que possa haver uma alternativa ao git diff"formato combinado" que de fato produza essa saída mais simples, mas não consegui encontrá-la. Em segundo lugar, o vídeo que mencionei acima foi feito há 7 meses: por que aquele YouTuber está obtendo, por padrão, ao comparar dois commits, uma saída simples do Git (que é perfeitamente compreensível para mim), enquanto eu obtenho (para mim) uma saída incompreensível? Minha versão do Git é:

git version 2.48.1.windows.1

Um link simples para uma página que explique genuinamente essa questão específica de git diffcomparar dois commits, em termos claros e, principalmente, mostrando como obter um .exe simples diff, pode ser tudo o que preciso. Procurei muito e não encontrei.

Mais tarde .
O daoh-nvohter pode, por favor, dizer por que essa pergunta não vale a pena ser feita?

Tenho um repositório git hospedado no GitHub e um servidor Git LFS giftless auto-hospedado na minha própria nuvem pública. Eu uso um .lfsconfigpara apontar os hooks de commit para minha instância lfs em vez da do GitHub. Isso funciona corretamente por si só.

No entanto, meus serviços de nuvem são protegidos por mTLS usando um certificado e uma chave privada gerados pelo Cloudflare, que eu então uso OpenSSL para empacotar em um keystore protegido por senha PKCS#12 para distribuição. Isso funciona para acessar meus serviços baseados na web por meio de navegadores, onde posso importar qualquer .pfxarquivo facilmente, mas não tenho certeza de como usar esse keystore com o git para permitir acesso ao servidor LFS (que é protegido pelo mesmo certificado).

Trabalhando com esta resposta , tentei uma série de transformações no .p12arquivo usando OpenSSL e diferentes permutações da configuração de rede do Git , mas estou tendo alguma dificuldade em descobrir onde cada parte do keystore precisa ser definida nas httpopções. Toda vez, recebo a seguinte saída ao tentar enviar para o LFS do meu repositório:

(test-ca.crt e test-cl.crt são derivados do arquivo .p12 anteriormente)

$ git -c http.sslcainfo=test-ca.crt -c http.sslCert=test-cl.crt \
  -c http.sslCertPasswordProtected lfs push origin main

Password for 'cert:///test-cl.crt':

warning: Authentication error: Authentication required: 
         Authorization error: https://git-lfs.my-cloud.com/user/repo/locks/verify
Check that you have proper access to the repository

Isso faz com que os arquivos rastreados pelo LFS não sejam enviados para o armazenamento de objetos.

Tenho clientes confiáveis ​​na minha nuvem que também precisam de acesso a este servidor LFS, que usam diferentes sistemas operacionais, incluindo Ubuntu e Windows. Não tenho certeza se git-basho Windows usaria o repositório global de certificados de usuário do SO para LFS, e não consigo descobrir como instalar um certificado de cliente em todo o sistema no Ubuntu também.