Desenvolvimento e produção do fluxo de trabalho GIt - onde devo criar os repositórios?

Question

Eu li em algum lugar* que uma configuração como esta seria legal:

Duas filiais principais, uma para cada servidor.

Pressionar para master envia as alterações para live;

Empurrar para dev/stage (ou como você chama) envia alterações para o teste;

Fluxo de trabalho:

• Crie uma ramificação do dev;

• trabalhe localmente até estar pronto para testar;

• mesclar de volta ao dev;

• push to Hub, que envia alterações para o servidor dev/staging.

Quando estiver pronto para ir ao ar:

• mesclar de dev para master,

• em seguida, envie o master para o Hub, que envia essas alterações para o servidor ativo.

Duas filiais principais, uma para cada servidor.

Então, eu tenho um ramo "Produção" em "Webroot/myliveApp/" e outro ramo "Desenvolvimento" em "Webroot/Devapp/"

Onde deveria estar o repositório?

ATUALIZAR:

Quero dizer:

Teremos, de acordo com este fluxo:

• Repositório principal;

• Hub de repositório vazio;

• Clones;

Os ramos de desenvolvimento e produção devem pertencer a um repositório, certo?

Se isso estiver correto, devemos emitir o PRIMEIRO comando git init?Em nosso repositório Prime?

Então teremos:

"webroot/myliveapp/" - ramo de produção;

"webroot/devapp/" - ramo de desenvolvimento;

"webroot/.git" - Repositório principal;

Isso faz sentido ?

Ou o repositório Prime deveria corresponder à localização da nossa filial de produção?

*Observação:se você precisar de um contexto sobre qual fluxo de trabalho estou tentando implementar, é este:http://joemaller.com/990/a-web-focused-git-workflow/

Answer 1

Obrigado pela atualização da sua pergunta, está mais claro agora.

Acredito que o problema que você está enfrentando se baseia em um mal-entendido sobre o fluxo de trabalho do Git;Git não é igual diretórios para filiais, equivale a um visualização do seu sistema de arquivos para filiais.Isso é poderoso - mas fácil de dar um tiro no próprio pé.Deixe-me explicar.

O Git atua mais como um sistema de arquivos de rastreamento de histórico baseado em banco de dados e com versões diferenciadas.Está "acima" do seu sistema de arquivos, não "parte dele".Ele não usa seu sistema de arquivos para representar ramificações, mas quando você faz check-out de uma ramificação diferente, todos os arquivos em seu sistema de arquivos serão alterados para serem os arquivos daquele branch.Você está pedindo ao Git para fazer seu sistema de arquivos representar a realidade alternativa desse ramo.

Se você estiver na filial master, e tem um arquivo root/foo.txt confirmado, e você verifica o branch experiment, o que faz não ter root/foo.txt confirmado, você encontrará esse arquivo perdido quando você procura por isso.É uma parte master, não experiment, e, portanto, não está presente no seu sistema de arquivos.É por isso que o Git é realmente exigente quanto ao commit do seu branch atual antes de permitir que você troque de branch - se você tiver alterações não planejadas em seu sistema de arquivos que o Git não conhece, ele se recusa a destruí-las, substituindo-as por uma realidade diferente.Você tem que intervir para consertar as coisas primeiro.

Então, para responder à pergunta, não crie subdiretórios para "myliveapp" e "devapp" - crie diferentes galhos.Basta ter sua base de código em "webroot".Em seguida, ataque, digamos, o branch "instável", confirmando suas alterações normalmente.Você pode então alternar todos os arquivos em seu repositório para a versão dos arquivos do seu servidor de desenvolvimento, alternando para o branch "devapp" e, da mesma forma, pode voltar para "instável" a qualquer momento.

Quando você deseja atualizar um branch, por ex.fazendo uma atualização do seu servidor de desenvolvimento, você pode merge "instável" em "devapp".Isso fará com que todos os arquivos do "devapp" pareçam com os do "instável", atualizando-o.

Outra coisa a ser observada:a diferença entre um repositório principal, um repositório simples e clones é quase nula.Praticamente não há diferença no software;em vez disso, é uma convenção humana dizer "o kernel do Linus é o kernel canônico do Linux".Com esse entendimento:

• Um repositório principal é apenas um repositório que todos concordam que contém a versão “canônica” do software.Ou seja, sempre que um desenvolvedor fez uma mudança que quer que todos vejam, em vez de dizer: "Puxe minha versão do Devapp", eles podem dizer: "Eu publiquei minhas alterações em nosso repositório principal". É simplesmente uma convenção fácil para as pessoas se unirem.
• Um clone é uma cópia de algum outro repositório.Eu poderia clonar o repositório principal, fazer alterações e então você pode clonar meu repositório.Se você fizer alterações, poderá enviá-las para o repositório principal ou para o meu, desde que a mesclagem seja válida e você tenha permissões no computador.
• Um repositório simples simplesmente não possui uma "cópia de trabalho" - não existe um diretório "webroot" nesse computador.Está vazio com apenas o .git diretório - o que é adequado para servidores onde ninguém precisa alterar os arquivos.

finalmente, o .git dir não contém os arquivos do seu repositório, ele contém a configuração e o banco de dados do git.É todo o histórico do seu repositório em formato de banco de dados, que é usado para preencher o restante do repositório com uma versão específica do seu software.Por isso fiz o comentário:você pode localmente Confira qualquer versão de qualquer realidade alternativa do repositório, sem comunicação de rede, a qualquer momento - porque está tudo no diretório .git.A única comunicação de rede necessária é quando você deseja sincronizar seu repositório local para algum outro repositório, usando push ou pull.