Fluxo de trabalho do servidor de produção / teste de Git


108

Atualmente meu site (servidor de produção) já tem muitos códigos nele. E agora eu quero começar a usar Git para meus projetos e configurar um servidor de teste para minha equipe. Alguém pode me dar algum conselho?

Aqui está a imagem em minha mente:

        Production        - Production server which already have codes
            ↑             
         Staging          - New staging server, will install Trac too
         ↗↙ ↖↘          
  Developer1  Developer2  - Local development 

Minha pergunta é: como devo começar?

Aqui estão alguns passos em minha mente:

  1. fazer um git initservidor em produção (isso é seguro?)
  2. clone o repo da produção para o servidor de teste
  3. desenvolvedores, cloneo repo da preparação para a máquina local
  4. push arquivos para o servidor de teste após terminar de alterar
  5. quando a encenação está pronta, pushtudo para a produção

Esse fluxo de trabalho faz sentido ou há alguma maneira melhor de fazer isso?

E se eu quiser alterar apenas um arquivo?

A origem / mestre tem algo a ver com isso neste processo? Quem é a origem? vou acabar tendo múltiplas origens ??

Além disso, quando um desenvolvedor deve usar branchneste caso?

Respostas:


59

É melhor usar o branch master apenas para o branch de produção e desenvolvimento do Staging. Cada desenvolvedor deve criar um branch local para adicionar novos recursos e então fundir com o branch de desenvolvimento. Se você é novo no git, tente usar - http://github.com/nvie/gitflow Há também uma boa imagem descrevendo o modelo de ramificação git - http://nvie.com/posts/a-successful-git- modelo de ramificação /


Esta é uma resposta melhor. Eu não estava muito familiarizado com o conceito de ramificação Git.
kayue

@erro. Você tem um link para algum recurso explicando o branch de desenvolvimento -> enviar para o sistema de teste e o branch master -> enviar para o servidor de produção com mais detalhes? O excelente artigo Um modelo de ramificação Git bem-sucedido não menciona essa parte, mesmo que mencione conceitos muito bons de ramificação e versionamento.
Edgar Alloro

19

Sua sugestão parece boa, mas eu não deixaria os desenvolvedores enviarem diretamente para o servidor de teste. Em vez disso, um integrador deve revisar cuidadosamente os branches e incorporá-los ao branch principal (ou branch de desenvolvimento, se você usar o modelo de fluxo git sugerido por bUg.) * A mesma pessoa enviaria para o servidor de teste.

* Integrador : " Uma pessoa bastante central que atua como integrador em um projeto de grupo recebe as alterações feitas por outros, revisa e integra-as e publica o resultado para que outros usem ... "


1. faça um git init no servidor de produção (isso é seguro?)

Sim, é seguro, mas é claro que você deve definir permissões muito restritivas neste repo. Eu provavelmente começaria transferindo curltodo o site para um disco local, se ainda não o tiver.

2. clonar o repo da produção para o servidor de teste

Você provavelmente deve ter um repositório "central" separado dos servidores de produção e de teste. Esse pode ser clonado e empurrado conforme necessário.

3. os desenvolvedores clonam o repo do teste para sua máquina local

4. Envie os arquivos para o servidor de teste após terminar de alterar

5. quando o teste estiver pronto, envie tudo para a produção

Substitua "staging" por "central" e acho que você está bem, mas um problema maior é como você trabalhará com branches e mesclagens, como bUg aponta.


10
1: Para tornar o repositório Git seguro na produção, certifique-se de adicionar um arquivo .htaccess com "Negar tudo" dentro.
kayue

2
2: O repo "central" de Felixyz está se referindo ao repo puro. Use o comando --bare para criar um repositório vazio.
kayue

1
@keyue 1: Melhor ainda, adicione RedirectMatch 404 /\.gità sua produção .htaccess para proteger seus .gitignore , .gitattributes e .git pasta.
Leo
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.