Transição do Subversion para Git, como faço para empurrar para heroku graciosamente?

Question

Eu estava usando um Subversion para o meu controle de origem, combinado com git somente para implementar (push) para heroku. Meu padrão foi: copiar Atualização de trabalho local do último mestre no repositório Subversion remoto. Então não git commit e git push heroku (Git foi definido para ignorar coisas .svn). Esta cópia de trabalho eu só usado para empurrar para heroku, tive outra pasta subversion para fazer desenvolvimento ao vivo, e se comprometer com o repositório Subversion remoto para monitoramento.

Eu já mudei para git totalmente. Eu fiz uma importação completa do subversion em um novo repositório git remoto. Eu estive com sucesso trabalhando em minha cópia de trabalho local do repo git (origem), e empurrando alterações quando me convém (também colaborar com um outro desenvolvedor, mas eu basicamente executar a operação).

Minha pergunta:

Agora, gostaria de voltar para o meu outro cópia de trabalho git que eu já tinha sido usando para empurrar para heroku (que tem .svn / material nele também). Estou pensando em apenas adicionando meu novo repositório git como uma entrada [origem] no .git / config .. puxando as últimas alterações do meu novo git remoto, e empurrando para heroku, mas eu estou querendo saber se ele vai surtar .

Ele vai tentar se fundem e se confundem não é? E, mesmo que a atração trabalhado, vai a heroku remoto ficar confuso sobre um empurrão que se originou a partir de um novo repositório git?

Eu poderia espancar (excluir) que o trabalho de cópia (usado para empurrar para heroku de subversão), e fazer um novo clone do meu novo repositório git, em seguida, adicione heroku ao .git / config. Mas eu estou preocupado empurrando para heroku ainda fará com que ele se confundir, desde que eu usei para empurrar a partir de uma cópia de trabalho diferente.

Qualquer conselho seria ótimo!

Agradecemos antecipadamente!

Answer 1

Se eu entendi corretamente, você quer voltar para o antigo repositório SVN como sua cópia de trabalho, e você quer preservar a história SVN velho?

Há um par de opções disponíveis.

1. Empurre as recentes alterações do novo repositório Git para Heroku, em seguida, mudar para o repositório antigo e puxar de Heroku. Isto irá levá-lo até repositório de idade à data.

2. Temporariamente mudar a URL no arquivo de configuração do velho repositório para apontar para o caminho local do novo repositório. Puxe as recentes mudanças de lá, e depois voltar para o Heroku URL quando terminar. Isso também irá trazer o seu repositório antigo até à data.

A primeira opção é a mais conveniente, eo segundo é o caminho mais longo. De qualquer maneira, você terá o mesmo resultado líquido de uma data até repositório local que contém toda a história. O novo repositório excedente pode ser descartado em qualquer caso.

Editar: Para resolver suas preocupações sobre se Heroku se preocupam com a origem do cometer, em breve, não o repositório no Heroku é outro repositório git que aceita submissões de usuários autenticados.

Enquanto as credenciais estiverem corretas, o repositório de origem não importa. Esta é a coisa bonita sobre DVCS - não há um controle ou repositório corruptível - É inteiramente possível para você agora clone de Heroku em outra máquina e continuar o trabalho de lá. Contanto que suas credenciais são os mesmos, a história vai mostrar todas e quaisquer commits você empurra, mas não se importa de onde.

Se o seu desejo é simplesmente usar um repositório limpo para trabalhar, o novo será o favorito. O velho pode ser suprimido sem efeitos nocivos.

Para provar isso - verificar os hashes SHA-1 para um commit em ambos os antigos e novos repositórios, e você vai ver que eles são idênticos. O hash é único para todos os commits, e pode ser usado para verificar a integridade do código em todos os momentos. Nunca haverá mais de uma mudança para qualquer hash.

• Como uma nota lateral, o repositório é portátil na medida em que é totalmente auto-contido, e pode ser movido livremente em seu espaço de armazenamento, ou até mesmo ser usado em armazenamento externo, como um pen drive USB.