Comment créer des branches privées distantes de perforce et y pousser ?

Question

Familiarisé avec git, première utilisation de perforce.

Je travaille sur ma propre fonctionnalité que je ne souhaite pas pousser vers le dépôt distant principal.

J'ai besoin de quelque chose comme des branches distantes git où :

1. Je peux valider mes changements. Quelque chose comme git commit

2. Je peux pousser vers une branche privée distante qui ne fusionne pas. Quelque chose comme git push remote my-branch

3. Peut fusionner les changements de la ligne principale dans ma branche. Quelque chose comme git merge master .

J'essaie de comprendre les branches p4, mais la terminologie est très confuse entre les deux. p4 integrate y p4 branch . De plus, toutes les étapes mènent à p4 submit qui se soumet à la ligne principale au lieu de ma branche. Existe-t-il un moyen de soumettre une branche privée à distance ?

J'ai essayé les étapes de la branche p4 ici : https://www.perforce.com/perforce/doc.973/cmdguide/html/branchin.htm Mais cela n'a pas conduit à se soumettre à la branche privée éloignée.

Answer 1

Perforce dispose d'un mode DVCS qui ressemble un peu à git, mais à moins qu'il n'y ait une raison impérative de ne pas le faire (comme une connectivité limitée ou de sévères contraintes de ressources sur le serveur), la façon typique d'utiliser Perforce est de tout faire directement sur le serveur central (le "référentiel distant"). p4 submit dans le modèle typique est essentiellement git commit + git push car votre "commit" va directement au serveur distant.

Ainsi, lorsque vous créez une branche, vous le faites également sur le serveur. Les branches dans Perforce sont simplement des dossiers qui sont copiés à partir d'autres dossiers (avec beaucoup de sémantique de suivi de fusion construite sur cette simple opération de copie), donc pour créer votre nouvelle branche de fonctionnalité à partir de //depot/main vous pourriez exécuter quelque chose comme :

p4 integ //depot/main/... //depot/features/road-rev/...
p4 submit

Cela crée une nouvelle branche dans le dépôt (en tant que dossier appelé features/road-rev ), et le synchronise également avec votre espace de travail, de sorte que maintenant tout ce que vous devez faire est :

cd features/road-rev
p4 add <new files>
p4 edit <existing files>
<etc>
p4 submit

Les changements que vous effectuez dans le road-rev sont complètement distinctes de la main branche. Pour tirer des changements plus récents de main vous ne faites que répéter la même chose integ que vous avez utilisée pour le créer, mais ajoutez une commande resolve pour gérer les fichiers qui doivent être fusionnés :

p4 integ //depot/main/... //depot/features/road-rev/...
p4 resolve -as
p4 resolve
p4 submit

Si vous exécutez la commande integrate dans le sens inverse (c'est-à-dire en inversant l'ordre des arguments), les changements sont fusionnés dans l'autre sens. Une fois que vous avez compris le concept selon lequel vous pouvez utiliser la commande integrate pour pousser arbitrairement les changements d'un ensemble de fichiers à un autre, la ramification est une question très simple de définition de différents ensembles de fichiers (généralement en tant que dossiers de premier niveau) pour représenter différentes variantes ramifiées du code -- ceci est appelé "ramification inter-fichier".

Si votre administrateur a configuré votre dépôt pour qu'il utilise la fonction ruisseaux le flux de travail est un peu différent (les flux sont des "branches gérées" qui sont censées ressembler un peu plus aux branches git auxquelles vous êtes habitués - vous ne pouvez avoir qu'un seul flux à la fois dans votre espace de travail, et vous utilisez la méthode de gestion des flux git. switch pour passer de l'un à l'autre, plutôt que de définir une commande vue du client qui fait correspondre des branches/fichiers arbitraires à des parties arbitraires de votre espace de travail). Vous avez toujours la même représentation sous-jacente de différentes variantes de branches correspondant à différents dossiers dans le dépôt, mais il y a tout un tas de sucre syntaxique par-dessus qui masque en quelque sorte cette représentation. Pour créer une branche de fonctionnalité à partir d'un flux, vous feriez :

p4 switch -c road-rev

qui est similaire à git checkout -b road-rev .