How to create private remote perforce branches and push to it?

Question

Familiar with git, first time using perforce.

I am working on my own feature which I would not like to push to mainline remote repository.

I need something like git remote branches where:

1. I can commit my changes. Something like git commit

2. I can push to remote private branch which does not merge. Something like git push remote my-branch

3. Can merge changes from mainline into my branch. Somthing like git merge master.

I am trying to understand p4 branches, but the confused with the terminology a lot between p4 integrate and p4 branch. Moreover all the steps lead to p4 submit which submits to the mainline instead of my branch. Is there a way to submit to remote private branch?

I have tried the p4 branch steps here: https://www.perforce.com/perforce/doc.973/cmdguide/html/branchin.htm But it did not lead to submitting to private remote branch.

Answer 1

Perforce has a DVCS mode that's somewhat git-like, but unless there's a compelling reason not to (like limited connectivity or severe resource constraints on the server), the typical way of using Perforce is to do everything directly on the central server (the "remote repository"). p4 submit in the typical model is essentially git commit + git push, because your "commit" goes directly to the remote server.

So when you create a branch, you're doing that on the server as well. Branches in Perforce are simply folders that are copied from other folders (with lots of merge tracking semantics built on top of that simple copy operation), so to create your new feature branch from //depot/main you might run something like:

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

This creates a new branch in the depot (as a folder called features/road-rev), and also syncs it to your workspace, so now all you need to do is:

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

Changes you make in the road-rev branch are completely separate from the main branch. To pull in newer changes from main you just repeat the same integ command you used to create it, but add a resolve to handle files that need merging:

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

If you run the integrate command in the opposite direction (i.e. swap the order of the arguments), then changes get merged in the other direction. Once you grok the concept that you can use integrate to arbitrarily push changes from one set of files to another, branching is a very simple matter of defining different sets of files (usually as top-level folders) to represent different branched variants of code -- this is called "inter-file branching".

If your admin has configured your depot to use streams the workflow is a little bit different (streams are "managed branches" that are meant to feel a little bit more like the git branches you're used to -- you can only have one stream in your workspace at a time, and you use the switch command to switch between them, rather than defining a client view that maps arbitrary branches/files to arbitrary parts of your workspace). You still have the same underlying representation of different branched variants being different folders in the depot, but there's a whole bunch of syntactic sugar on top that sort of hides that representation. To create a feature branch from a stream you'd do:

p4 switch -c road-rev

which is similar to git checkout -b road-rev.