Fluxo de trabalho Git para manter o software de código aberto modificado personalizado atualizado?

Question

Nossa universidade oferece hospedagem na web aos departamentos do campus nos servidores que gerenciamos. A instalação de programas de terceiros de código aberto requer a modificação de permissões e codificação do arquivo no programa antes que ele seja executado. (Estamos usando o SUEXEC, se você estiver familiarizado.)

Atualmente, oferecemos o WordPress por meio de um script do instalador. O usuário carrega a versão estável mais recente e executa um script PHP do lado do servidor via SSH. Este script PHP modifica as permissões de arquivos de todos os arquivos/pastas, Adiciona/remove algum código em vários arquivos e cria alguns novos arquivos. Este script do instalador é um ato de equilíbrio pesado quando uma nova versão estável é lançada.

Quero começar a usar o controle de versão (especificamente o GIT) para rastrear nossas alterações personalizadas em vez de confiar em um script para fazer as alterações, mas não tenho certeza do fluxo de trabalho para usar. Estou familiarizado com a ramificação e a fusão, mas não tenho certeza de como integrar nossas alterações antigas quando uma nova versão é emitida.

Qual deve ser o meu fluxo de trabalho Git para integrar as novas alterações no núcleo do WordPress, mas também preservar nossas alterações personalizadas mais antigas?

Answer 1

Eu sugeriria manter suas alterações em uma filial e rebatizar essa filial contra as últimas novidades do WordPress sempre que você atualizar. Em uma linha do tempo difícil ...

              +-- WordPress 1.0
              v
[master] --*--*
               \
[custom]        *--*--*     <- your customizations

Quando você deseja atualizar o WordPress, mude para o Master e faça um novo commit com o último souce (ou use Git-SVN para manter o mestre em sincronia):

              +-- WordPress 1.0
              |     +-- WordPress 1.1
              v     v
[master] --*--*--*--* 
               \
[custom]        *--*--*     <- your customizations

Agora você pode fazer um git rebase master custom Para reproduzir suas alterações contra as últimas, resolvendo quaisquer conflitos ao longo do caminho. Sua linha do tempo ficaria assim:

              +-- WordPress 1.0
              |     +-- WordPress 1.1
              v     v
[master] --*--*--*--* 
                     \
[custom]              *--*--*     <- your customizations

Atualizar: Para fornecer um pouco de justificativa ... Gosto dessa abordagem para esse problema, porque fornece uma clara diferenciação entre o código do WordPress e suas personalizações. Quando você obtém uma nova versão do WordPress, você realmente não está interessado em "integração". Você está interessado em reaplicar suas personalizações para a nova versão do WordPress. Na minha opinião, essa recustomização é mais facilmente feita com comprometimento por meio de uma rebase. Quaisquer conflitos significam que uma personalização provavelmente quebrou, de qualquer maneira, a antiga confirmação de personalização é o lixo de qualquer maneira - é melhor resolver o problema em sua fonte e manter o histórico atualizado limpo.

Depois master é atualizado e custom é renegado e empurrado, os colaboradores apenas rebaixariam seu trabalho em andamento contra o mais recente.

Esta é apenas a minha opinião, como um proponente firme de rebase> mescla. A beleza do git é que raramente há uma resposta certa. Continue ajustando até encontrar algo que funcione para você.

Answer 2

Minha abordagem geral é ter dois ramos, upstream e master. Crie seu repositório (que o iniciará no master ramo), verifique a cópia mais recente do código a montante que você usa e, em seguida, crie o upsteram ramo com git branch upstream. Além disso, crie uma tag indicando qual versão upstream você importou, como git tag wordpress-1.0. Normalmente, uso tags leves para isso (sem anotações, basicamente um ponteiro para uma revisão).

[wordpress-1.0]               Key: [tag]
v                                  branch
* <- upstream                      * commit
^- master 

Agora, enquanto você ainda está no master ramificar, copie suas alterações e verifique -as. Você agora tem duas filiais, upstream que contém a fonte a montante intocada e master que contém suas mudanças, com a história mostrando quais mudanças você fez para upstream.

[wordpress-1.0]
v
* <- upstream
 \
  +--* <- master 

Faça todas as suas modificações no master ramo.

[wordpress-1.0]
v
* <- upstream
 \
  +--*--*--* <- master 

Quando uma nova versão do código a montante aparecer, confira o seu upstream ramo (git checkout upstream), limpe tudo, menos o .git diretório e cópia na nova versão a montante. Usar git add -A Para encenar todas as alterações na versão a montante, comprometa -a e etiquetá -la.

[wordpress-1.0]
|  [wordpress-1.1]
v  v
*--* <- upstream
 \
  +--*--*--* <- master 

Agora, verifique master, e mesclar suas mudanças a montante. Nesse ponto, você pode escolher como se fundir, como pegar a nova versão a montante, pegar sua versão ou fazer alterações mescladas, assim como você faz em uma mesclagem normal.

[wordpress-1.0]
|  [wordpress-1.1]
v  v
*--*--------+ <- upstream
 \           \
  +--*--*--*--* <- master 

Então, todas as suas mudanças acontecem em master, e todas as versões upstream são comprometidas exatamente como é upstream. Isso permitirá que você veja mais facilmente exatamente como seu código difere da versão a montante, ele ajudará a acompanhar quais alterações você já se fundiu com a versão a montante e assim por diante.

[wordpress-1.0]
|  [wordpress-1.1]
|  |           [wordpress-2.0]
v  v           v
*--*--------+--*-+ <- upstream
 \           \    \ 
  +--*--*--*--*----*--* <- master 

Espero que isso ajude, deixe -me saber se você tiver mais alguma dúvida.