Puxe para outro ramo Git sem alternar

55

recentemente mudamos de SVN para Git e, ao mesmo tempo, colocamos nossos sistemas ao vivo no controle de versão (em vez de check-out local e cópia de arquivo ao vivo).

No projeto ao qual estou designado, todos acessamos o mesmo repositório e, para obter alterações no live, estamos git pulllá. Isso causa problemas porque nossos webdesigners enviam alterações para o VCS que ainda não deveriam estar no ar, mas deveriam estar no ambiente de teste na web.

Quando um dos desenvolvedores agora entra em operação, ele recebe todas as alterações (possivelmente inacabadas).

Pensei em mudar ao vivo para um ramo extra e apenas mesclar o que mudou, mas devido à minha falta de conhecimento do git, não faço ideia de como.

Minha ideia é:

Crie uma nova ramificação em live ( git branch live).
Toda vez que algo tem que ir ao ar
- Puxe alterações no mestre (como git checkout master; git pull; git checkout live:)
- git merge master

O problema é que mudar para o master ou puxar tudo diretamente para o sistema ativo causaria problemas, então eu preferiria evitar isso.

Existe alguma maneira de fazer isso ou existe uma maneira melhor de gerenciar o sistema Live (exceto para treinar os webbies para não empurrar coisas inacabadas).

git

— Morfildur
fonte

git pull --allpor padrão, não puxará o mestre para o live, ele puxará o master e o mesclará com o master e (se existir no servidor) puxará o live para mesclar no live. Você tentou?

— Tobias Kienzler 16/07/10

Seu problema foi causado por um arquivo que não estava sob controle de versão antes de sair do live e adicionado ao git após a modificação para dominar mais tarde? Foi o que aconteceu comigo antes, geralmente deve ser suficiente renomear temporariamente esse arquivo ou, se não for necessário ao vivo , use-o git checkout -fpara ignorar o problema - mas faça um backup!

— Tobias Kienzler

1

related: stackoverflow.com/questions/3216360/…

— Ciro Santilli escreveu:

21

Você pode usar git stashantes de verificar o master e puxar e, depois de verificar o live novamente, use git stash pop(ou se o seu git for mais antigo git stash applye git stash clearsupondo que você não escondeu mais nada)

— Tobias Kienzler
fonte

6

git pull --allirá buscar todos os controles remotos, mas ainda tentará mesclar um ramo (ou o ramo padrão) no ramo atual também.

— Mipadi

@ mipadi sim, mas apenas o ramo atual em si mesmo, sem tentar fazer check-out do mestre e causar o conflito, não?

— Tobias Kienzler

Ele mesclará qualquer ramificação configurada para ser automaticamente mesclada na ramificação atual (se essa ramificação estiver configurada).

— Mipadi

1

@ Superole Está documentado como "buscar todos os controles remotos", que inclui não apenas vários repositórios, mas também ramificações. Embora em retrospectiva, git fetch --allpode ter sido uma resposta melhor

— Tobias KIENZLER

2

@TobiasKienzler Ele instrui apenas o git a buscar em todos os controles remotos configurados. O caso mais comum é ter apenas uma origem nomeada remota. Se você tiver mais de um controle remoto com o mesmo ramo que o seu atual, e eles não estiverem em um relacionamento de avanço rápido, ENTÃO, usar a --allopção fornecerá uma fusão de polvo das diferentes versões do ramo no atual ! Portanto, meu conselho é ficar longe, a --allmenos que seja isso que você procura, porque na maioria dos outros casos isso não lhe dará nada.

— Superole

74

Eu era capaz de puxar mudanças a partir de origin/masterdentro master, enquanto trabalhava em outro ramo usando o comando:

git fetch origin master:master

— Jeff B
fonte

6

Impressionante! Exatamente o que eu estava procurando - isso precisa ser muito mais bem documentado ...

— Markus Shepherd

2

Você pode encontrar documentação sobre isso aqui: git-scm.com/docs/git-fetch#_examples

— c1moore

fetch! =pull

— D. Kovács

5

Resolva o problema primeiro. Eles não devem empurrar para uma filial para a qual não têm negócios.

O que você parece estar perguntando seria algo como

git checkout live
git pull origin master

Isso tentará mesclar o mestre remoto e sua ramificação ativa.

— Josh K
fonte

O problema é que atualmente temos apenas um ramo e não será possível mudar isso, já que todos estão muito acostumados ao SVN e não estão dispostos a aprender as vantagens de algo novo. Só será possível criar uma nova ramificação no diretório ativo. Mesclar o mestre remoto ao ramo ativo é o que eu quero evitar, pois não posso impedir que alguém forneça código de depuração, funções incompletas, erros de sintaxe e qualquer outra coisa para o mestre (afinal, sou apenas o desenvolvedor júnior). Agradeço-te pela tua sugestão mesmo assim.

— Morfildur 13/07/10

2

@ dbeme: Você pode usar tarballs e patches. ;) A menos que eles estejam dispostos a aprender git (e não é difícil de ramificar e mesclar), você terá problemas.

— 21710 Josh K

0

Eu recomendo que você crie um repositório de teste git para que todos possam confirmar. Todos os repositórios, incluindo o site ao vivo, serão clones do repositório de testes. Dessa maneira, qualquer pessoa pode fazer o teste sem tocar no site ao vivo. Quando alguém precisar atualizar o site ativo, você poderá extrair o site ativo do repositório de testes do git. Esse fluxo de trabalho é bastante semelhante ao SVN. Para flexibilidade extra, recomendo usar o ramo "ao vivo" que você descreve.

Para resumir, o repositório git de todos é um clone do repositório de testes. O site de produção ao vivo também é apenas um clone do repositório de testes. Como alternativa, o teste pode ser um clone da produção ao vivo, para que um "empurrãozinho" sempre se mova em direção à produção.

Outras opções, incluindo a adição da ramificação "ativa" a esse arranjo ou a inclusão de um repositório "intermediário" entre teste e produção. Para segurança extra, recomendo restringir o acesso ao repositório ao vivo do git e forçar as pessoas a usar um script seguro que faça a atração para a produção ao vivo.

— edgester
fonte