Como modificar uma confirmação especificada?


2233

Normalmente, envio uma lista de confirmações para revisão. Se eu tiver as seguintes confirmações:

  1. HEAD
  2. Commit3
  3. Commit2
  4. Commit1

... Eu sei que posso modificar o commit da cabeça git commit --amend. Mas como posso modificar Commit1, já que não é o HEADcommit?


31
Veja uma resposta alternativa aqui: stackoverflow.com/a/18150592/520567 Sua resposta aceita é realmente uma resposta exata para sua pergunta, mas se você tiver seu novo commit pronto antes de decidir usar a edição, essa resposta será mais direta. Ele também pode funcionar com várias confirmações que você deseja mesclar / squash junto com uma mais antiga.
akostadinov

6
Além disso, você pode apenas ver Dividindo uma confirmação no Git Tools - Rewriting History para obter mais informações.
hakre

Respostas:


2956

Você pode usar o git rebase . Por exemplo, se você deseja modificar a confirmação bbc643cd, execute

$ git rebase --interactive 'bbc643cd^'

Observe o sinal de intercalação ^no final do comando, porque você realmente precisa voltar ao commit antes do que deseja modificar .

No editor padrão, modifique pickpara editna linha mencionando 'bbc643cd'.

Salve o arquivo e saia: o git irá interpretar e executar automaticamente os comandos no arquivo. Você se encontrará na situação anterior em que você acabou de criar o commit bbc643cd.

Neste ponto, bbc643cdé o seu último commit e você pode alterá-lo facilmente : faça as alterações e depois confirme com o comando:

$ git commit --all --amend --no-edit

Depois disso, digite:

$ git rebase --continue

para retornar ao commit HEAD anterior.

AVISO : Observe que isso alterará o SHA-1 desse commit e de todos os filhos - em outras palavras, isso reescreve o histórico a partir desse ponto. Você pode interromper os repositórios fazendo isso se pressionar usando o comandogit push --force


125
Outra opção interessante nesse fluxo é que, depois de passar para o commit que você deseja modificar, em vez de modificar os arquivos e colocar o commit no topo (aquele que você está editando), convém dividir esse commit em dois commit diferentes. (ou até mais). Nesse caso, volte para o commit para editar e execute "git reset HEAD ^". que colocará os arquivos modificados dessa confirmação no estágio. Agora escolha e confirme os arquivos que desejar. Esse fluxo é bastante bem explicado na página do manual "git-rebase". Consulte a seção "Divisão de confirmações". bit.ly/d50w1M
Diego Pino

200
No Git 1.6.6 e mais recente, você pode usar a rewordação em git rebase -ivez de edit(ela abre automaticamente o editor e continua com as demais etapas de rebase; isso evita o uso git commit --ammende git rebase --continuequando você só precisa alterar a mensagem de confirmação e não o conteúdo )
precisa

108
Vale a pena notar que talvez você precise executar git stashantes git rebasee git stash popdepois, se houver alterações pendentes.
user123444555621

3
Existe um comando shortucut para editar uma confirmação específica na rebase interativa sem abrir o editor, localizando a confirmação, marcando-a como edição e retornando à linha de comando?
SSTUR

15
Observe que, com o git mais recente, seria mais prudente seguir instruções rápidas em vez de usar cegamente git commit --all --amend --no-editaqui. Tudo o que eu tinha que fazer depois git rebase -i ...era git commit --amendnormalmente então git rebase --continue.
21717 Eric

453

Use a fantástica rebase interativa:

git rebase -i @~9   # Show the last 9 commits in a text editor

Encontre a confirmação que você deseja, altere pickpara e( edit) e salve e feche o arquivo. O Git retrocederá para esse commit, permitindo que você:

  • use git commit --amendpara fazer alterações ou
  • use git reset @~para descartar a última confirmação, mas não as alterações nos arquivos (ou seja, levá-lo ao ponto em que você estava quando editou os arquivos, mas ainda não havia confirmado).

O último é útil para fazer coisas mais complexas, como dividir em várias confirmações.

Em seguida, execute git rebase --continuee o Git repetirá as alterações subsequentes sobre o commit modificado. Você pode ser solicitado a corrigir alguns conflitos de mesclagem.

Nota: @é uma abreviação para HEAD, e ~é o commit antes do commit especificado.

Leia mais sobre como reescrever o histórico nos documentos do Git.


Não tenha medo de se recuperar

ProTip ™: Não tenha medo de experimentar comandos "perigosos" que reescrevem o histórico * - O Git não exclui seus commits por 90 dias por padrão; você pode encontrá-los no reflog:

$ git reset @~3   # go back 3 commits
$ git reflog
c4f708b HEAD@{0}: reset: moving to @~3
2c52489 HEAD@{1}: commit: more changes
4a5246d HEAD@{2}: commit: make important changes
e8571e4 HEAD@{3}: commit: make some changes
... earlier commits ...
$ git reset 2c52489
... and you're back where you started

* Cuidado com opções como --harde no --forceentanto - elas podem descartar dados.
* Além disso, não reescreva o histórico nos ramos em que você está colaborando.



Em muitos sistemas, git rebase -io Vim será aberto por padrão. O Vim não funciona como a maioria dos editores de texto modernos, então veja como fazer uma nova recuperação usando o Vim . Se você preferir usar um editor diferente, altere-o com git config --global core.editor your-favorite-text-editor.


29
O meio da sua resposta é um lugar estranho para colocar o que eu só posso descrever como um anúncio miniture para o VIM. É irrelevante para a pergunta e apenas atrapalha sua resposta.
Intentss

21
@ Intentss: Ah, eu posso ver por que isso parecia estranho. O raciocínio por trás disso era que o Vim é o editor de texto padrão em muitos sistemas; a primeira experiência de rebasing interativo de muitas pessoas é uma tela em que a digitação faz o cursor girar por todo o lugar. Em seguida, eles trocam seu editor para outra coisa, e sua segunda experiência de rebasing interativo é bastante normal, mas os deixa se perguntando por que ele usa um arquivo de texto em vez de uma GUI. Para obter fluxo com o rebasing, você precisa de algo como o Vim, ou o modo de rebase do Emacs.
Zaz 30/05

9
OK. Como muitas pessoas acham essa parte irrelevante, eu a condensei em três linhas e também expliquei como alterar o editor, se necessário.
Zaz

17
Impressionante! Eu não sabia que você poderia usar @como taquigrafia HEAD. Obrigado por postar isso.
James Ko

3
git reset @~exatamente o que eu queria fazer depois de escolher confirmar git rebase .... Você é o meu herói)
18 /

79

Interativa rebase com --autosquashé algo que eu freqüentemente uso quando preciso Fixup commits anteriores mais profunda na história. Essencialmente, acelera o processo ilustrado pela resposta do ZelluX e é especialmente útil quando você tem mais de um commit que precisa editar.

A partir da documentação:

--autosquash

Quando a mensagem de log de confirmação começar com "squash! ..." (ou "correção! ...") e houver uma confirmação cujo título comece com o mesmo ..., modifique automaticamente a lista de tarefas de rebase -i para que a confirmação marcado para esmagar vem logo após o commit ser modificado

Suponha que você tenha um histórico parecido com este:

$ git log --graph --oneline
* b42d293 Commit3
* e8adec4 Commit2
* faaf19f Commit1

e você tiver as alterações que deseja alterar no Commit2, confirme suas alterações usando

$ git commit -m "fixup! Commit2"

Como alternativa, você pode usar o commit-sha em vez da mensagem de confirmação, portanto, "fixup! e8adec4ou mesmo apenas um prefixo da mensagem de confirmação.

Em seguida, inicie um rebase interativo na confirmação antes

$ git rebase e8adec4^ -i --autosquash

seu editor será aberto com os commits já ordenados corretamente

pick e8adec4 Commit2
fixup 54e1a99 fixup! Commit2
pick b42d293 Commit3

tudo o que você precisa fazer é salvar e sair


21
Você também pode usar em git commit --fixup=@~vez de git commit -m "fixup! Commit2". Isso é especialmente útil quando as mensagens de confirmação são mais longas e seria difícil digitar tudo.
Zaz

42

Corre:

$ git rebase --interactive commit_hash^

cada um ^indica quantas confirmações você deseja editar, se for apenas uma (o hash de confirmação que você especificou), basta adicionar uma ^.

Usando Vim você mudar as palavras pickpara rewordos commits que pretende alterar, salvar e sair ( :wq). Em seguida, o git solicitará cada confirmação que você marcou como reformulação, para que você possa alterar a mensagem de confirmação.

Cada mensagem de confirmação que você precisa salvar e sair ( :wq) para ir para a próxima mensagem de confirmação

Se você quiser sair sem aplicar as alterações, pressione :q!

EDIT : para navegar vimvocê jcostuma subir, kdescer, hir para a esquerda e lir para a direita (tudo isso no NORMALmodo, pressione ESCpara ir para o NORMALmodo). Para editar um texto, pressione ipara entrar no INSERTmodo em que você insere o texto. Pressione ESCpara voltar ao NORMALmodo :)

UPDATE : Aqui está um ótimo link da lista do github Como desfazer (quase) qualquer coisa com o git


4
Funcionou perfeitamente para mim. Vale mencionar git push --force?
u01jmg3

O que git push --forcefaz é substituir os controles remotos confirmados pelos confirmados locais. Isso não é o caso deste tópico :)
betoharres

@BetuUuUu, é claro, se suas confirmações são enviadas para remoto e você modificou a mensagem de confirmação localmente, você deseja forçar o envio para remoto, não é?
Sudip Bhandari

@SudipBhandari Esse é o sentimento que tenho. Não forcei, e agora tenho um ramo extra, espelhando todos os commits de volta para aquele cuja mensagem eu mudei, o que é super feio.
Ruffin

2
@greenhouse se você modificar e pressionar com força, outros membros da equipe provavelmente encontrarão conflitos conflitantes. Então você deve ser super cauteloso em relação a isso. Mas se você modificar algo que ninguém mais buscou ainda, tudo ficará bem (a empresa não notará). Portanto, consideraria --force como último recurso e sempre consultaria o estado do repositório com outros membros.
Tomasz Kaczmarzyk

18

Se, por algum motivo, você não gostar de editores interativos, poderá usá-lo git rebase --onto.

Digamos que você queira modificar Commit1. Primeiro, ramifique antes Commit1 :

git checkout -b amending [commit before Commit1]

Segundo, pegue Commit1com cherry-pick:

git cherry-pick Commit1

Agora, corrija suas alterações, criando Commit1':

git add ...
git commit --amend -m "new message for Commit1"

E finalmente, depois de ocultar outras alterações, transplante o restante de seus commits até mastero novo commit:

git rebase --onto amending Commit1 master

Leia: "rebase, na ramificação amending, tudo confirma entre Commit1(não inclusivo) e master(inclusivo)". Ou seja, Commit2 e Commit3, cortando completamente o antigo Commit1. Você pode simplesmente selecioná-los, mas dessa maneira é mais fácil.

Lembre-se de limpar seus galhos!

git branch -d amending

4
você pode usar git checkout -b amending Commit1~1para obter a prévia comprometer
Arin Taylor

Os dois primeiros passos são equivalentes git checkout -b amending Commit1?
Haoshu 24/01

16

Baseado na documentação

Alterando a mensagem de mensagens de confirmação mais antigas ou múltiplas

git rebase -i HEAD~3 

O exemplo acima exibe uma lista dos últimos 3 confirmados no ramo atual, altere 3 para outro se desejar mais. A lista será semelhante à seguinte:

pick e499d89 Delete CNAME
pick 0c39034 Better README
pick f7fde4a Change the commit message but push the same commit.

Substitua pick por reformular antes de cada mensagem de confirmação que você deseja alterar. Digamos que você altere o segundo commit na lista, seu arquivo terá a seguinte aparência:

pick e499d89 Delete CNAME
reword 0c39034 Better README
pick f7fde4a Change the commit message but push the same commit.

Salve e feche o arquivo da lista de confirmação, isso exibirá um novo editor para você alterar sua mensagem de confirmação, alterar a mensagem de confirmação e salvar.

Por fim, pressione com força os commits alterados.

git push --force

Eu recebo o seguinte erro: error: Houve um problema com o editor 'vi'. Forneça a mensagem usando a opção -m ou -F.
Erick Maynard

12

Comando completamente não interativo (1)

Eu apenas pensei em compartilhar um alias que estou usando para isso. É baseado em rebase interativa não interativa. Para adicioná-lo ao seu git, execute este comando (explicação abaixo):

git config --global alias.amend-to '!f() { SHA=`git rev-parse "$1"`; git commit --fixup "$SHA" && GIT_SEQUENCE_EDITOR=true git rebase --interactive --autosquash "$SHA^"; }; f'

A maior vantagem desse comando é o fato de não ser vim .


(1) dado que não há conflitos durante o rebase, é claro

Uso

git amend-to <REV> # e.g.
git amend-to HEAD~1
git amend-to aaaa1111

O nome amend-toparece IMHO apropriado. Compare o fluxo com --amend:

git add . && git commit --amend --no-edit
# vs
git add . && git amend-to <REV>

Explicação

  • git config --global alias.<NAME> '!<COMMAND>'- cria um alias global do git chamado <NAME>que executará o comando não-git<COMMAND>
  • f() { <BODY> }; f - uma função bash "anônima".
  • SHA=`git rev-parse "$1"`; - converte o argumento em revisão git e atribui o resultado à variável SHA
  • git commit --fixup "$SHA"- correção-confirmação para SHA. Veja git-commitdocumentos
  • GIT_SEQUENCE_EDITOR=true git rebase --interactive --autosquash "$SHA^"
    • git rebase --interactive "$SHA^" parte foi coberta por outras respostas.
    • --autosquashé o que é usado em conjunto com git commit --fixup, consulte os git-rebasedocumentos para obter mais informações
    • GIT_SEQUENCE_EDITOR=trueé o que torna a coisa toda não interativa. Este truque eu aprendi com este post do blog .

1
Também se pode fazer amend-toarquivos unstaged punho: git config --global alias.amend-to '!f() { SHA=git rev-parse "$ 1"; git stash -k && git commit --fixup "$SHA" && GIT_SEQUENCE_EDITOR=true git rebase --interactive --autosquash "$SHA^" && git stash pop; }; f'
Dethariel

2
Uma preocupação com esse método é que ele pode aplicar correções não relacionadas.
Ciro Santilli escreveu:

O objetivo da pergunta não é alterar a mensagem de confirmação? Porque esta resposta não aborda isso, ou pelo menos não diretamente.
Wytten

@wytten a pergunta não pergunta sobre a alteração da mensagem de confirmação, trata-se de modificar a confirmação do não é HEAD. Assim, uma resposta à sua pergunta seria "não, não é o ponto da questão"
Dethariel

Estou confuso, então como podemos mudar a mensagem de confirmação?
Gb667

8

Edição de rebase interativa automatizada seguida de confirmação de confirmação pronta para uma reforma

Eu encontrei-me corrigindo um commit passado com frequência suficiente para escrever um script para ele.

Aqui está o fluxo de trabalho:

  1. git commit-edit <commit-hash>
    

    Isso o deixará no commit que você deseja editar.

  2. Corrija e prepare o commit como deseja, em primeiro lugar.

    (Você pode usar git stash savepara manter os arquivos que não está enviando)

  3. Refaça o commit com --amend, por exemplo:

    git commit --amend
    
  4. Conclua a rebase:

    git rebase --continue
    

Para que o procedimento acima funcione, coloque o script abaixo em um arquivo executável chamado git-commit-editem algum lugar do seu $PATH:

#!/bin/bash

set -euo pipefail

script_name=${0##*/}

warn () { printf '%s: %s\n' "$script_name" "$*" >&2; }
die () { warn "$@"; exit 1; }

[[ $# -ge 2 ]] && die "Expected single commit to edit. Defaults to HEAD~"

# Default to editing the parent of the most recent commit
# The most recent commit can be edited with `git commit --amend`
commit=$(git rev-parse --short "${1:-HEAD~}")
message=$(git log -1 --format='%h %s' "$commit")

if [[ $OSTYPE =~ ^darwin ]]; then
  sed_inplace=(sed -Ei "")
else
  sed_inplace=(sed -Ei)
fi

export GIT_SEQUENCE_EDITOR="${sed_inplace[*]} "' "s/^pick ('"$commit"' .*)/edit \\1/"'
git rebase --quiet --interactive --autostash --autosquash "$commit"~
git reset --quiet @~ "$(git rev-parse --show-toplevel)"  # Reset the cache of the toplevel directory to the previous commit
git commit --quiet --amend --no-edit --allow-empty  #  Commit an empty commit so that that cache diffs are un-reversed

echo
echo "Editing commit: $message" >&2
echo

7

Chegou a essa abordagem (e provavelmente é exatamente o mesmo que usar o rebase interativo), mas para mim é meio simples.

Nota: Apresento essa abordagem para ilustrar o que você pode fazer, em vez de uma alternativa cotidiana. Uma vez que tem muitos passos (e possivelmente algumas advertências).

Digamos que você queira alterar o commit 0e que você está atualmentefeature-branch

some-commit---0---1---2---(feature-branch)HEAD

Faça o checkout para este commit e crie um quick-branch. Você também pode clonar sua ramificação de recursos como um ponto de recuperação (antes de iniciar).

?(git checkout -b feature-branch-backup)
git checkout 0
git checkout -b quick-branch

Agora você terá algo parecido com isto:

0(quick-branch)HEAD---1---2---(feature-branch)

Mudanças de palco, escondem tudo o mais.

git add ./example.txt
git stash

Confirme as alterações e faça o checkout de volta para feature-branch

git commit --amend
git checkout feature-branch

Agora você terá algo parecido com isto:

some-commit---0---1---2---(feature-branch)HEAD
           \
             ---0'(quick-branch)

Rebase feature-branchpara quick-branch(resolva quaisquer conflitos ao longo do caminho). Aplique o esconderijo e remova quick-branch.

git rebase quick-branch
git stash pop
git branch -D quick-branch

E você acaba com:

some-commit---0'---1'---2'---HEAD(feature-branch)

O Git não duplicará (embora eu não possa realmente dizer até que ponto) o 0 se compromete ao rebasear.

Nota: todos os hashes de confirmação são alterados a partir do commit que originalmente pretendemos alterar.


6

Para obter um comando não interativo, coloque um script com este conteúdo no seu PATH:

#!/bin/sh
#
# git-fixup
# Use staged changes to modify a specified commit
set -e
cmt=$(git rev-parse $1)
git commit --fixup="$cmt"
GIT_EDITOR=true git rebase -i --autosquash "$cmt~1"

Use-o organizando suas alterações (com git add) e depois execute git fixup <commit-to-modify>. Obviamente, ainda será interativo se houver conflitos.


1
Isso funciona bem. Eu adicionei algumas funcionalidades extras para fazer reparos fragmentados de uma árvore suja para aperfeiçoar um conjunto de confirmação. `dirtydiff = $ (diff do git); if ["$ {dirtydiff}"! = ""]; depois ecoar "Esconder árvore suja"> & 2; esconderijo; fi;
Simon Feltman

6

git stash+ rebaseautomação

Pois quando eu preciso modificar um commit antigo muitas vezes para as análises da Gerrit, eu venho fazendo:

git-amend-old() (
  # Stash, apply to past commit, and rebase the current branch on to of the result.
  current_branch="$(git rev-parse --abbrev-ref HEAD)"
  apply_to="$1"
  git stash
  git checkout "$apply_to"
  git stash apply
  git add -u
  git commit --amend --no-edit
  new_sha="$(git log --format="%H" -n 1)"
  git checkout "$current_branch"
  git rebase --onto "$new_sha" "$apply_to"
)

GitHub upstream .

Uso:

  • modificar arquivo de origem, não é necessário git addse já estiver no repositório
  • git-amend-old $old_sha

Gosto disso --autosquashporque não esmaga outros consertos não relacionados.


Solução muito boa, essa deve ser uma opção padrão git amendpara aplicar alterações em um commit específico com o uso do stash atual, muito inteligente!
caiohamamura 12/02

5

Eu resolvi isso

1) criando um novo commit com as mudanças que eu quero ..

r8gs4r commit 0

2) eu sei qual commit eu preciso mesclar com ele. que é confirmar 3.

então, o git rebase -i HEAD~4nº 4 representa o commit recente 4 (aqui o commit 3 está em quarto lugar)

3) no rebase interativo, o commit recente estará localizado na parte inferior. será parecido,

pick q6ade6 commit 3
pick vr43de commit 2
pick ac123d commit 1
pick r8gs4r commit 0

4) aqui precisamos reorganizar o commit, se você deseja mesclar com um específico. deveria ser assim,

parent
|_child

pick q6ade6 commit 3
f r8gs4r commit 0
pick vr43de commit 2
pick ac123d commit 1

após reorganizar, você precisa substituir p pickpor f(a correção será mesclada sem a mensagem de confirmação) ou s(a mesclagem de squash com a mensagem de confirmação pode mudar no tempo de execução)

e salve sua árvore.

agora mesclar feito com confirmação existente.

Nota: Seu método não é preferível, a menos que você faça a manutenção por conta própria. se você tem um tamanho grande de equipe, não é um método aceitável para reescrever a árvore git, acabará em conflitos que você sabe que outros não. se você quiser manter sua árvore limpa com menos commits, tente isso e se sua equipe pequena não for preferível .....


Essa é uma boa solução, se você não quiser fazer modificações ao vivo durante uma nova recuperação interativa.
Dunatotatos

4

A melhor opção é usar o "comando rebase interativo" .

O git rebasecomando é incrivelmente poderoso. Permite editar mensagens de confirmação , combinar confirmações, reordená-las ... etc.

Toda vez que você refaz uma confirmação, um novo SHA será criado para cada confirmação, independentemente do conteúdo ser alterado ou não! Você deve ter cuidado ao usar esse comando, pois ele pode ter implicações drásticas, especialmente se você trabalhar em colaboração com outros desenvolvedores. Eles podem começar a trabalhar com seu commit enquanto você está refazendo alguns. Depois de forçar a enviar os commits, eles ficarão fora de sincronia e você poderá descobrir mais tarde em uma situação confusa. Por isso tem cuidado!

É recomendável criar uma backupramificação antes de rebasear, para que, sempre que encontrar coisas fora de controle, você possa voltar ao estado anterior.

Agora como usar este comando?

git rebase -i <base> 

-isignifica "interativo" . Observe que você pode executar uma nova refazer no modo não interativo. ex:

#interactivly rebase the n commits from the current position, n is a given number(2,3 ...etc)
git rebase -i HEAD~n 

HEADindica sua localização atual (também pode ser o nome da filial ou confirmar o SHA). Os ~nmeios "n beforeé, assim HEAD~nserá a lista de" n "confirmados antes do que você está atualmente.

git rebase tem comando diferente como:

  • pou pickmanter o comprometimento como está.
  • rou reword: para manter o conteúdo do commit, mas altere a mensagem do commit.
  • sou squash: para combinar as alterações desse commit no commit anterior (o commit acima dele na lista).
  • ... etc.

    Nota: É melhor fazer o Git trabalhar com seu editor de código para simplificar as coisas. Por exemplo, se você usar código visual, poderá adicionar assim git config --global core.editor "code --wait". Ou você pode pesquisar no Google como associar você preferiu seu editor de código ao GIT.

Exemplo de git rebase

Queria alterar os 2 últimos commits que fiz, então processo assim:

  1. Exiba as confirmações atuais:
    #This to show all the commits on one line
    $git log --oneline
    4f3d0c8 (HEAD -> documentation) docs: Add project description and included files"
    4d95e08 docs: Add created date and project title"
    eaf7978 (origin/master , origin/HEAD, master) Inital commit
    46a5819 Create README.md
    
  2. Agora eu uso git rebasepara alterar as 2 últimas mensagens confirmadas: $git rebase -i HEAD~2 Abre o editor de código e mostra o seguinte:

    pick 4d95e08 docs: Add created date and project title
    pick 4f3d0c8 docs: Add project description and included files
    
    # Rebase eaf7978..4f3d0c8 onto eaf7978 (2 commands)
    #
    # Commands:
    # p, pick <commit> = use commit
    # r, reword <commit> = use commit, but edit the commit message
    ...
    

    Desde que eu quero mudar a mensagem de confirmação para este 2 confirma. Então, eu vou digitar rou rewordno lugar de pick. Salve o arquivo e feche a guia. Observe que rebaseé executado em um processo de várias etapas, portanto, o próximo passo é atualizar as mensagens. Observe também que as confirmações são exibidas em ordem cronológica reversa, de modo que a última confirmação seja exibida nessa e na primeira confirmação na primeira linha e assim por diante.

  3. Atualize as mensagens: Atualize a primeira mensagem:

    docs: Add created date and project title to the documentation "README.md"
    
    # Please enter the commit message for your changes. Lines starting
    # with '#' will be ignored, and an empty message aborts the commit.
    ...
    

    salvar e fechar Editar a segunda mensagem

    docs: Add project description and included files to the documentation "README.md"
    
    # Please enter the commit message for your changes. Lines starting
    # with '#' will be ignored, and an empty message aborts the commit.
    ...
    

    salvar e fechar.

  4. Você receberá uma mensagem como essa no final do rebase: o Successfully rebased and updated refs/heads/documentationque significa que você terá sucesso. Você pode exibir as alterações:

    5dff827 (HEAD -> documentation) docs: Add project description and included files to the documentation "README.md"
    4585c68 docs: Add created date and project title to the documentation "README.md"
    eaf7978 (origin/master, origin/HEAD, master) Inital commit
    46a5819 Create README.md
    

    Eu desejo que possa ajudar os novos usuários :).


2

Para mim, foi para remover algumas credenciais de um repositório. Tentei refazer o processo e encontrei uma tonelada de conflitos aparentemente não relacionados ao tentar refazer o processo - continuar. Não se preocupe em tentar se recuperar, use a ferramenta chamada BFG (brew install bfg) no mac.


0

Se você ainda não enviou as confirmações, pode voltar para uma confirmação anterior usando git reset HEAD^[1,2,3,4...]

Por exemplo

git commit <file1> -m "Updated files 1 and 2"
git commit <file3> -m "Updated file 3"

Ops, esqueci de adicionar o arquivo2 ao primeiro commit ...

git reset HEAD^1 // because I only need to go back 1 commit

git add <file2>

Isso adicionará o arquivo2 ao primeiro commit.


0

Bem, essa solução pode parecer muito boba, mas pode salvá-lo em determinadas condições.

Um amigo meu acabou acidentalmente cometendo muitos arquivos enormes (quatro arquivos gerados automaticamente, variando entre 3 GB a 5 GB cada) e depois fez alguns códigos adicionais, além disso, antes de perceber o problema que git pushnão estava mais funcionando!

Os arquivos foram listados, .gitignoremas após renomear a pasta do contêiner, eles foram expostos e confirmados! E agora havia mais algumas confirmações do código, mas pushestavam em execução para sempre (tentando fazer upload de GB de dados!) E finalmente falhariam devido aos limites de tamanho de arquivo do Github .

O problema com o rebase interativo ou algo semelhante era que eles lidavam com esses arquivos enormes e levavam uma eternidade para fazer qualquer coisa. No entanto, depois de passar quase uma hora na CLI, não tínhamos certeza se os arquivos (e deltas) foram realmente removidos do histórico ou simplesmente não foram incluídos nos commits atuais. O empurrão também não estava funcionando e meu amigo estava realmente preso.

Então, a solução que surgiu foi:

  1. Renomeie a pasta git atual para ~/Project-old.
  2. Clone a pasta git novamente do github (para ~/Project).
  3. Checkout para o mesmo ramo.
  4. Manualmente cp -ros arquivos da ~/Project-oldpasta para ~/Project.
  5. Verifique se os arquivos enormes, que não precisam ser verificados, estão mveditados e incluídos .gitignorecorretamente.
  6. Além disso, certifique-se de não substituir a .gitpasta clonada recentemente ~/Projectpela antiga. É aí que vivem os registros da história problemática!
  7. Agora revise as alterações. Deve ser a união de todos os commits recentes, excluindo os arquivos problemáticos.
  8. Finalmente confirme as alterações, e é bom ser pusheditado.

O maior problema dessa solução é que ela lida com a cópia manual de alguns arquivos e também mescla todas as confirmações recentes em uma (obviamente com um novo hash de confirmação).

Os grandes benefícios são que, é muito claro em todas as etapas, funciona muito bem para arquivos grandes (além de sensíveis) e não deixa nenhum vestígio na história!

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.