Perforce equivalent of git local commit

I just started using Perforce after using Git for a year. Is there any equivalent of a git local commit to my branch in perforce.

Essentially, if I want to work on a complex task which might need undoing and redoing of my specific changes, is there any way to accomplish this in Perforce? The way I would do it in Git would be committing my changes to a branch and having several commits within the branch before merging in to master.

  • How to branch and merge properly with Git?
  • Git in TFS - Remove branches after merging
  • git: track a remote branch not on origin
  • Git: How to merge a small, but very old branch?
  • Can I branch in Mercurial without cloning the repository?
  • Install package with pip from specific branch of github
  • Using GitPython module to get remote HEAD branch
  • github non fast-forward error
  • TFS 2015 build stuck on GIT PUSH
  • Git Version Control - Views on Repositories?
  • Git Subtrees vs Monorepo
  • Why is my git submodule command not working with Bitbucket?
  • 3 Solutions collect form web for “Perforce equivalent of git local commit”

    I think p4 shelve might be useful to you here.

    Longer answer:

    The way p4 works is that you have to unlock a file using p4 edit, or add a new file using p4 add. This will create a changelist that basically has all the files that are staged for your next commit.

    p4 submit can then be used to push (in git terminology) all the changes in your changelist to the repository/depot.

    Now if you don’t want to submit right away, you can shelve those changes using p4 shelve. This will create a local checkpoint of your changelist which you can go back to, or undo. You may also create multiple shelved copies building one after the other. You can probably replicate all the functions of a git commit with this command.

    See the p4 shelve command reference for more details.

    The classic way of doing this in Perforce would be to do exactly what you say — create a branch, submit to that branch, then merge it back. One difference vs Git is that each change made on your branch is permanent, with later changes building on earlier ones — you don’t undo earlier commits by removing them from the history, you just make additional versions. Another change is that when you merge back, you’re creating a new changelist on the target branch that contains the sum total of all of the changes you’re merging from the source — so rather than squashing the changes together on your branch, you squash the changes when you merge. You can potentially do the merge in stages and even merge in a different order from when the changes happened on your branch, so that the history on the main branch might look different from the history in your branch (but it maintains pointers back to your branch as well).

    The current public beta release of Perforce (2015.1) offers a more Git-like approach in which you would split off a local Perforce repository, make changes, and potentially rewrite your history before pushing it back up to the shared repository — the “local” history isn’t necessarily visible anywhere on the shared server, since you have the option of rewriting it (whereas any history committed to the central server, on any branch, is forever unless an admin obliterates it). More about Perforce’s new DVCS capabilities (again, this is still in beta):

    There does not appear to be a way to accomplish what you want without using a bridge tool to connect Git with Perforce.

    I am in the same situation as you in my current job and we have considered trying out a Git-Perforce bridge. Perforce has a bridge to Git called git-fusion which is free for up to 20 users. This is probably the best bridge tool there is. Git itself provides a command called git p4 which gives you some more limited functionality. Your workflow using git p4 will look something like this:

    # do your work and make your git commits
    git p4 rebase
    git p4 submit

    As you might have guessed, git p4 rebase goes to the repository and gets all changes made by other users in that branch before committing your work on top. Rebasing is necessary because it simulates Perforce where all of your commits always remain intact.

    If you decide to go with a bridge tool, realize that this will likely a big IT infrastructure change and you may have to convince your organization that it is worth undertaking.

    Git Baby is a git and github fan, let's start git clone.