Trabalhando com Git e Perforce: fluxo de trabalho de integração
Então, este é o cenário: sua equipe trabalha com independência em um repositório do Git, mas uma parte da empresa ainda usa o Perforce para gerenciar partes da mesma base de código. Essas equipes no Perforce não estão planejando migrar, mas sua equipe já fez a transição para o Git (por muitos bons motivos). É importante que você possa manter um processo de compartilhamento de código bidirecional em andamento entre as bases de código para que as melhorias desenvolvidas em qualquer versão possam ser compartilhadas, de preferência sem custar muito tempo ou atolar demais sua equipe.
É aqui que entra este guia. Na TomTom, essa operação de sincronização é feita uma vez a cada novo lançamento — o que, no caso deles, acontece uma vez a cada mês e meio.
-- Este post foi escrito em colaboração com Andrea Carlevato, Adolfo Bulfoni e Krzysztof Karczewski, que tiveram a gentileza de compartilhar o processo do Git usado na unidade de aplicativos de navegação da TomTom. --
Suposições antes de começarmos
Vamos supor que você já está familiarizado com o uso básico do Git e familiarizado com um fluxo de trabalho de ramificação de função. Caso contrário, reserve um tempo para assistir a um tutorial prático ou a um webinar. Volte quando estiver pronto, vamos esperar.
Como existem algumas sutilezas a serem lembradas no processo, sugerimos ter muito cuidado ao realizar essas integrações. Vamos nos aprofundar quando você estiver pronto!
Instalando o git p4
O primeiro passo é instalar a ponte. Verifique se você já a instalou digitando em uma linha de comando:
git p4Se o sistema reclamar que o git p4 não está instalado, baixe git-p4.py e coloque-o em uma pasta em seu PATH, por exemplo ~/bin (obviamente você vai precisar que o Python também esteja instalado para que ele funcione).
Torne-o executável com:
chmod +x git-p4.py
Edite o arquivo ~/.gitconfig adicionando:
[alias]
p4 = !~/bin/bit-p4.py
Em seguida, execute o git p4 de novo e você não vai receber erros. A ferramenta está instalada.
Material relacionado
Como mover um Repositório do Git completo
VER SOLUÇÃO
Aprenda a usar o Git com o Bitbucket Cloud
Visão geral do fluxo de trabalho
Clone inicial
Como os projetos no P4 podem desenvolver histórias enormes, a equipe pode escolher um ponto de corte para sincronizar, economizando muito espaço e tempo. O git p4 permite que você escolha a lista de alterações a partir da qual iniciar o rastreamento:
git p4 clone //depot/path/project@<earlier-cutoff-point>,<latest-changelist>- Agora podemos executar uma sincronização e verificar se recebemos todos os conjuntos de alterações no local:
git p4 sync
O comando sync encontra novas alterações no P4 e as importa como commits do Git.
- A ramificação que vamos usar para interagir direto com o Perforce é nomeada
p4-integ. Neste ponto, queremos apenas ramificá-la doremotes/p4/main:
git checkout -b p4-integ origin/p4/main
Sincronização rápida de acompanhamento (também conhecida como "atrair e trocar")
Após a conclusão da primeira importação, as sincronizações subsequentes do git-> p4 podem ser feitas com os seguintes comandos:
git checkout p4-integ
git p4 syncO de cima funciona, mas pode ser lento. Uma maneira muito mais rápida de executar a sincronização é recriar referências idênticas às usadas na integração mais recente. Essa também é uma maneira interessante de garantir que qualquer novo desenvolvedor encarregado da integração comece na lista correta de commit/alteração.
Veja como fazer isso:
- Remova as
referênciasoriginais antigas (ou obsoletas) do remotop4(opcional):
git symbolic-ref -d refs/remotes/p4/HEAD
git update-ref -d refs/remotes/p4/main- Crie referências remotas artificiais (também conhecidos como falsas) que apontam para o último commit no
p4-integnaorigem:
git update-ref refs/remotes/p4/main remotes/origin/p4-integ
git symbolic-ref refs/remotes/p4/HEAD refs/remotes/p4/mainA única desvantagem dessa sincronização muito mais rápida é que precisamos especificar explicitamente a ramificação no git p4. Então, este é o comando final:
git p4 sync --branch=refs/remotes/p4/main
A maneira como o git p4 rastreia o mapeamento entre os IDs de commit do Git e os P4 é anotando os commits com metadados:
Merge pull request #340 in MOB/project from bugfix/PRJ-3185 to develop
Squashed commit of the following:
commit c2843b424fb3f5be1ba64be51363db63621162b4
Author: Some Developer
Date: Wed Jan 14 09:26:45 2015 +0100
[PRJ-3185] The app shows ...
commit abc135fc1fccf74dac8882d70b1ddd8a4750f078
Author: Some Developer
Date: Tue Jan 13 14:18:46 2015 +0100
[PRJ-3185] The app shows the rating ...
[git-p4: depot-paths = "//depot-mobile/project/": change = 1794239]Observe que em uma versão mais recente do git p4, os metadados para associar um commit do Git a uma lista de alterações P4 são armazenados em uma nota de commit e não na mensagem do commit. A equipe da TomTom não gostou da mudança porque deu um pouco mais de trabalho verificar os números da lista de alterações quando necessário.
Mover as alterações do git para o Perforce
Depois que a operação de sincronização rápida acima for concluída, agora você está pronto para fazer push das alterações do git para o Perforce.
O primeiro passo é fazer o rebase do p4-integ com as alterações provenientes do remotes/p4/main:
git checkout p4-integ
git p4 rebaseDepois disso, todas as novas alterações do Perforce devem estar no p4-integ para que possamos atualizar o principal:
- Depois disso, você pode apenas:
git checkout main
git merge develop- Tenha as tags mais recentes no local:
git fetch --tags- Use uma
limpezatemporária caso você precise remover os commits já emP4(consulte a tagP4no commit). Caso nenhum commit deva ser ignorado, um rebase automático que vai linearizar o histórico:
git checkout -b cleanup #branching off from main
git rebase -s recursive -X theirs tag/last-p4-integ- Usando um rebase interativo, essa ação pode ser feita com:
git rebase -i tag/last-p4-integ
- Use
cherry-pickpara escolher os novos commits e colocá-los na ramificaçãop4-integ. Fazemos dessa maneira porque não fazemos suposição de que as ramificaçõesgitprincipaledesenvolvimentopossam ser mantidas como ancestrais próprias da ramificaçãop4-integ. Na verdade, na TomTom, esse não é mais o caso.
git checkout p4-integ
git cherry-pick tag/last-p4-integ..cleanup- Envie para
P4e sincronizep4-integ:
git p4 submit
git p4 sync --branch=refs/remotes/p4/main
git reset --hard refs/remotes/p4/main- Excluir ramificação de rebase temporária:
git branch -D cleanup
- Remova o ponteiro para o ponto de integração mais recente (tag) no local e no remoto:
git tag -d tag/last-p4-integ
git push origin :refs/tags/tag/last-p4-integ- Atualize a tag
last-p4-integpara apontar para o novo ponto de integração emP4:
git checkout develop
git tag -a tag/last-p4-integ -m "tag pointer to last develop commit integrated with p4"
git push origin main
git push origin tag/last-p4-integ
git push origin p4-integExecute testes na base de código P4 para verificar se a integração não apresentou problemas.
Mover as alterações do Perforce para o git
Isso deve ser feito depois que o push git->P4 já tiver sido feito. Depois que os testes forem bem-sucedidos no P4, agora podemos mover as alterações de P4 para git com o seguinte:
git checkout p4-integ
git p4 sync --branch=refs/remotes/p4/main
git p4 rebase- O que vem a seguir é um pequeno truque para executar uma estratégia robusta de merge "deles", esmagando as alterações recebidas em um único commit. Então aqui vai:
git checkout -b p4mergebranch #branching off from p4-integ
git merge -s ours main ## ignoring all changes from main
git checkout main
git merge p4mergebranch --squash
git commit -m "Type your integration message"git branch -D p4mergebranch
- Quando terminarmos a etapa acima, faça o merge das alterações para
desenvolvimento:
<p>Bitbucket has the following space stations:</p>
<p>
<b>Earth's Moon</b><br>
Headquarters
</p>Como pode ter havido algumas alterações desde que escolhemos as alterações do desenvolvimento, pode haver a necessidade de fazer o merge delas primeiro. É importante, no entanto, atualizar a tag last-p4-integ para o commit correto, em especial não atualizar o commit de merge a ser desenvolvido. Para fazer isso de forma segura, é melhor marcar o estado atual do principal:
- Remova a tag antiga no local e no remoto:
git tag -d tag/last-p4-integ
git push origin :refs/tags/tag/last-p4-integ- Crie uma tag na nova posição:
git checkout main
git tag -a tag/last-p4-integ -m "tag pointer to last develop commit integrated with p4"- Agora envie
principal, desenvolvimento, p4-integetag/last-p4-integparaorigem:
Conclusões
É assim que você sincroniza entre duas equipes de desenvolvimento ativas usando o Git e o Perforce. O processo acima evoluiu ao longo do tempo na TomTom e agora está sendo executado sem grandes problemas há algum tempo. Funciona, mas é uma boa quantidade de despesas gerais a serem mantidas. Se você tiver a opção, recomendamos migrar completamente para o Git.
De qualquer forma, se você seguir uma abordagem diferente para manter uma sincronização bidirecional, eu ficaria muito curioso para ouvir o que você tem a dizer nos comentários abaixo. Ou envie um tweet para @durdn ou @atlassiandev.
Mais uma vez obrigado a Andrea Carlevato, Adolfo Bulfoni e Krzysztof Karczewski.
Compartilhar este artigo
Próximo tópico
Leitura recomendada
Marque esses recursos para aprender sobre os tipos de equipes de DevOps ou para obter atualizações contínuas sobre DevOps na Atlassian.
Blog do Bitbucket
Caminho de aprendizagem de DevOps
