I have been playing around with Git. I’m a big fan of perforce. After using GIT, I’m a bigger fan of perforce.
Git thinks differently — It assumes that all developers don’t trust each other, and only a “core few” really have rights to the source tree. Each developer then works on their own dev branch. Git also thinks of the changelist — you “add files” to a change. Perforce thinks of the filesystem — You “add files” VIA the change. The difference between “to the change” and “Via the change” is very different. Here’s a quick mapping of perforce commands to their GIT equal.
p4 add –> git add
p4 edit –> git add
p4 submit — > git commit, then git push, then pull ( pull request if you’re not trusted, push if you’re trusted. )
p4 opened –> git status
p4 info –> git remote -v
p4 branch X “//depot/foo/… //depot/bar/…” –> Different concept. Perforce is using the branch as a map between one depot namespace and another. Git uses the branch as a changelist tracker. You can kind of map between them, but the differences can get you if you’re not careful.
- git checkout -b bar
git push -u origin bar
p4 integrate //depot/foo/… //depot/bar/… –> many steps in git Assuming branches foo/bar exist:
- git pull origin foo — this “syncs” the foo “namespace” ( origin tracker in git-speak ).
- git checkout bar — this switches to the bar “namespace”.
- git merge foo — the actually plays the diffs between the two spaces.
- git commit — you’ll need to resolve first, the commit the change locally.
- git push — same as p4 submit.
In Git, common branch names are “master” and “develop”. In perforce, there’s not really a concept of master, but rather, a depot namespace mapped to a client workspace. Git doesn’t map — your clone matches the source tree of the branch you’re working on, always. Again, I think perforce’s maps are better for developers, who often work on really small chunks of the tree, and don’t really need to clone an entire tree.