Perforce branching vs git branching

Question

I am a Git user trying to learn Perforce.

In Git a user can checkout from the main branch, change some files and push his code to the server on a different branch with a specific commit ID.

Another Git user can checkout that new branch using its commit ID and work on top of it.

How can this be performed using Perforce?

Answer 1

I am a Git user trying to learn Perforce.

I'm sorry.

How can this be performed using Perforce?

I'm a better Git user than I am a Perforce user, so correct me if anything appears wrong. I highly recommend reading the man pages and a tutorial.

It "can't" be, at least not quite the way Git does it.

In git, when you create a branch, you're branching the entire state of the repository. Perforce does not support this, rather, it's "branching" is more per-file: i.e., you branch file A into file B, at which point file B contains a back reference to file A saying "I came from here." This back reference can then be used to determine a common ancestor for merging purposes. My understanding, however, is that these back references are per-file, and you are free to integrate (merge) any file into any other. (Compare to git, where "Parent commit" is your back-reference, but is on a whole-repository scale.)

You can branch entire sets of files using p4 integrate, using the typical Perforce syntax (e.g., //depot/some/path/...). Typically, you'd branch a whole directory to a whole other directory, such as //depot/main/my_project into //depot/release-1.0/my_project, or something similar. Perforce, as far as I know, doesn't really care about the paths: it just "branches" files from one location to another. Any pattern or sanity in the paths is up to you.

Additionally, you can use p4 branch to create "branch specifications", which are basically a way to record the source set of files and their destinations, to make branching easier. (If you take the release example, you may want to eventually merge back changes, or merge further changes into the release, etc.)

Both times I've worked with Perforce, branches were a beast of a different nature than in Git, and there's a bit of a culture difference here. Branches were comparatively rare. (I only saw them used for releases, ever.) We did not use them for feature branches, except perhaps the largest of features; compare to git, where to me a "feature branch" is usually "it took >1 commit".

Answer 2

If you despise Perforce as much as I do then you should continue using Git. I should say that I'm much more comfortable using Git.

I currently use Git-P4 + a set of Bash scripts I wrote (git-p4-helpers)

I follow a simplified variation of this workflow:

$ git checkout p4-integration
$ git p4 sync
$ git p4 rebase
$ git tag last-green <SHA1> # last green build
$ git rebase last-green develop
$ git checkout -b <my-feature>
$ git commit # as needed
# Sync Git->P4 (see Github:git-p4-helpers)
# Submit using P4

There's still one thing I haven't been able to figure out, namely how to submit from Git-P4 to P4 fast (every time I have tried it takes forever to doing git p4 sync then a bunch of other stuff that make it very annoying to submit from my Git repo directly to P4. So I wrote a script to sync my Git repo with my P4 workspace and then Submit using P4.

For now this allows me to use all the features of Git while I'm working on my changes, then I just submit using P4.

Answer 3

Remember that perforce makes a copy for a branch where Git just makes a pointer to the new branch, which is much faster.