There's probably not a lot of such documentation because Perforce is a pretty traditional revision control system (closer to CVS, Subversion, etc.) and normally is considered to be less complicated than modern distributed revision control systems.
Trying to map commands from one to the other is not the right approach; concepts from centralized vs. distributed revision control systems aren't the same. Instead, I'll describe a typical workflow in Perforce:
- Run
p4 edit
on each file you want to edit. You need to tell Perforce which files you're editing. If you're adding new files, use p4 add
. If you're deleting files, use p4 delete
.
- Make your code changes.
- Run
p4 change
to create a changeset. Here you can create a description of your change and optionally add or remove files from your changeset too. You can run p4 change CHANGE_NUMBER
to edit the description later if necessary.
- You can make additional code changes if you need to. If you need to add/edit/delete other files, you can use
p4 {add,edit,delete} -c CHANGE_NUMBER FILE
.
- Run
p4 sync
to pull in the latest changes from the server.
- Run
p4 resolve
to resolve any conflicts from syncing.
- When you're ready to submit your change, run
p4 submit -c CHANGE_NUMBER
.
You can use p4 revert
to revert your changes to files.
Note that you can be working on multiple changesets simultaneously as long as none of their files overlap. (A file in your Perforce client can be open in only one changeset at a time.) This sometimes can be convenient if you have small, independent changes.
If you find yourself needing to edit files that you already have open in another changeset, you can either create a separate Perforce client or you can stash your existing changeset for later via p4 shelve
. (Unlike git stash
, shelving does not revert the files in your local tree, so you must revert them separately.)