Como começo a usar o Git para diferentes bases de código de diferentes servidores?

Histórico: recentemente herdei um conjunto de projetos na minha empresa e estou tentando resolver alguns problemas fundamentais de como eles foram tratados. Nomeadamente, os desenvolvedores anteriores (que não estão mais na empresa) não estavam usando nenhuma forma de controle de origem, fizeram pouca documentação e realmente não possuíam bons processos de desenvolvimento.

Então agora eu tenho três servidores no valor de projetos (desenvolvimento, preparação, produção), que consistem principalmente de sites e aplicativos e ferramentas criadas para aplicativos e APIs de terceiros que usamos, até lojas de scripts SQL e outras coisas. Meu primeiro pensamento foi colocar tudo isso no Git antes que mudanças e correções fossem feitas, mas estou tendo dificuldades para descobrir a melhor maneira de fazer isso.

Muito do desenvolvimento anterior foi feito diretamente nos servidores de produção, o que criou uma divisão entre a base de código de cada servidor. Não está claro imediatamente onde estão todas as diferenças - estou vendo correções de erros no lado da produção que não são transportadas no desenvolvimento / preparação, bem como novos recursos no desenvolvimento que não foram movidos para a preparação / produção .

Pergunta: Qual seria a melhor maneira de organizar e mover essas informações para o Git? Como estruturaria meus repositórios / ramificações para acomodar as diferenças no código?

Eu considerei o desenvolvimento contínuo de clones do código do servidor de produção e mantendo as bases de código de desenvolvimento / preparação como referência histórica. Isso seria potencialmente um ponto de partida, considerando que eu não sei nada sobre o código de desenvolvimento / teste de qualquer maneira? Eu poderia simplesmente criar repositórios de servidores de produção para cada site, ferramenta, conjunto de scripts etc., criar ramificações para o código de desenvolvimento / teste existente, e qualquer novo desenvolvimento ramificaria da base de códigos do servidor de produção. Isso faz sentido?

Coloque o material de produção na masterfilial de um novo repositório. Crie uma developramificação a partir disso e mescle o servidor intermediário nele. Você pode acabar com conflitos que precisam ser resolvidos. Uma vez que aqueles são resolvidos, criar outra feature_branchde develope mesclar o servidor de desenvolvimento para ele. Resolva os conflitos que surgirem.

Isso deixa você com três filiais, que representam seus ambientes de produção, preparo e desenvolvimento. Produção -> master, estadiamento -> develop, desenvolvimento -> feature_branch. Portanto, todo o desenvolvimento é feito feature_branchese somente é incorporado à developramificação quando o recurso é concluído, testado e estável. Por ser estável, pode ser usado como teste. Corte um releasegalho a partir do developmomento em que estiver pronto para o lançamento, amarre as pontas soltas, junte-o mastere faça a sua nova produção.

Uma de suas primeiras ordens de negócios após a configuração deve ser mesclar as informações de feature_branchvolta em develop* e, em seguida, developnovamente master. Lembre-se de que ele feature_branchpode conter código e recursos não testados; portanto, tenha cuidado ao mesclá-lo develope depois master. Feito isso, todas as ramificações devem conter o mesmo código, e qualquer desenvolvimento que foi feito no servidor de produção agora é portado de volta para o "servidor" de desenvolvimento.

Nesse modelo, cada projeto estaria em seu próprio repositório, e esse repositório teria um mastere developbranch, mais feature_branchesqualquer trabalho sendo realizado.

EDIT, para endereçar comentários: Sim, este é o Gitflow.

Essa estratégia (ou Gitflow em geral) mantém o sistema de três níveis existente (produção, preparação, desenvolvimento) com um caminho claro de mesclagem do desenvolvimento até a produção. Importar as bases de código dessa maneira também permite que as ramificações sejam sincronizadas enquanto mantém o status quo na produção - pelo menos até que as mesclagens possam ser testadas. Isso alcança alguns objetivos: obtém o código no controle de origem, sincroniza e mescla as diferentes bases de código (para que não haja mais correções na produção, mas não no desenvolvimento) e fornece um bom processo para usar no futuro (um processo bem definido e usado por muitas pessoas / equipes / empresas). Se o OP achar que o Gitflow não é adequado para seus projetos / equipes / empresa à medida que o usa / a empresa cresce, então será '

* Você pode recortar outro ramo de recurso e remover novos recursos óbvios e mesclar esse ramo em develop(e depois em master). Isso evita que você precise testar novos recursos além de todos os outros testes que você fará.

Vou recomendar o stagingcódigo como a melhor linha de base para sua importação inicial. Isso ocorre porque há alterações nas productionque não estão presentes staging, devido às correções, mas muito menos se houver alguma alteração nas stagingque não estão incluídas production. Da mesma forma, há alterações nas developmentque não estão presentes stagingdevido aos novos recursos, mas provavelmente muito menos se houver alguma alteração nas stagingque não estão incluídas development.

Observe que você não deseja stagingser sua linha de base após a importação inicial. Esta é apenas uma situação temporária devido a alterações que não foram rastreadas anteriormente. As operações de filial funcionam muito mais suavemente se você estiver adicionando alterações em vez de removê-las. Após a importação inicial, mude para o modelo de ramificação que melhor se adapte às suas necessidades.

Portanto, verifique seu stagingcódigo em uma stagingramificação, faça um git checkout -b master stagingpara criar sua masterramificação e verifique seu código de produção. Em seguida, faça um git checkout -b development stagingpara criar sua developmentramificação e verifique seu código de desenvolvimento.

Agora confira seu developmentramo e master entre nele. Isso permitirá que você resolva a enorme quantidade provável de conflitos de mesclagem, mantendo masterum registro do que realmente está em produção. developmentagora contém todas as alterações de todos os ambientes. Agora você pode mudar para o modelo de ramificação que melhor lhe convier.

É uma boa ideia ter a história. Eu criaria o repositório (ou um para cada produto) a partir do ambiente mais estável. Crie ramificações ou diferenças para os outros.

Em alto nível:

1. Crie um novo repositório
2. Em uma cópia de trabalho baseada em produção: adicione tudo, confirme e pressione
3. Mestre de checkout para um novo diretório
4. Para cada ambiente adicional XYZ
   1. Criar ramo Archive-XYZ
   2. Substitua tudo pelo XYZcódigo - fonte (exceto .git)
   3. adicione tudo, confirme e pressione

Como alternativa, se você é cético em relação ao valor disso, em git diff > XYZ.diffvez de realmente confirmar e empurrar, e arquivar as diferenças.

De qualquer maneira, você deve terminar em um estado em que possa comparar facilmente o código que está executando em cada ambiente, que pode ser usado para estabelecer um único ponto de partida para cada projeto. E, se algo quebrar, teoricamente você poderá comparar suas alterações com qualquer um dos três ambientes.