Git clone repetido vs pull

1

Caso de uso :

Eu tenho o MyApp que será implantado no ClientX. Eu estou escrevendo um script de shell para buscar esse ramo do meu repositório bitbucket

meu script de shell (funciona bem)

git clone -b $BRANCH_NAME https://[email protected]/MyApp/ecodrone.git

Pergunta :

Agora com atualizações, é melhor ter

  1. git clone todas as vezes
  2. um git-clone.sh e um git-pull.sh?
por Srinath Ganesh 18.05.2018 / 08:27

2 respostas

2

Se você tiver armazenamento persistente, a recodificação seria muito ineficiente (especialmente clonando todo o histórico, já que você não está usando --depth= ).

Enquanto isso, um pull / fetch só recebe objetos que foram realmente alterados. Use:

  • git fetch && git reset --hard "origin/$BRANCH_NAME" para sempre recuperar o commit mais recente,

  • ou git pull --ff-only se você preferir que ele falhe com dificuldade se alguém tentar reescrever um histórico.

Não use um git pull simples, pois isso pode causar uma grande confusão no último caso.

    
por 18.05.2018 / 08:48
1

Resposta curta:

  1. git pull

Para atualizar é melhor git pull ou git fetch, rebase e merge se você estiver trabalhando com outras pessoas na mesma ramificação (& / ou arquivos), pois o git pull tentará mesclar somente se não houver conflitos de mesclagem .

Além disso, seria melhor criar uma nova ramificação com base na ramificação que você clonou para resolver os conflitos de mesclagem localmente em seu computador com mais facilidade. Isso geralmente é chamado de ramificação de recurso no fluxo de trabalho. Desta forma, uma vez que seu trabalho esteja concluído e comprometido, você pode executar git pull no branch master (por falta de um nome eu estou chamando o branch you cloned master), isso deve acontecer sem problemas e então você pode rebase feature do master e mesclar (use o sinalizador --no-ff se desejar manter o registro de ramificação do recurso / histórico de confirmação, ele é espremido em um commit de outra forma) para masterizar. Então empurre seu trabalho (branch master) para cima.

deve ser algo como:

git checkout -b feature
...work, stage changes & commit...
git checkout master
git pull upstream/master #or git pull origin master based on git remote urls
git checkout feature
git rebase -i upstream/master
git checkout master 
git merge --no-ff master feature
git push upstream #or git push origin

Também não entendo porque você gostaria de cloná-lo novamente, a clonagem é supostamente uma coisa única para repositórios git

    
por 18.05.2018 / 08:55

Tags