Git users typically work with few restrictions since Git security is limited to the SSH or HTTP authentication needed to push changes to a remote repository. Using Git Fusion as a remote with the Perforce server as a backend, you can now take advantage of Perforce’s configurable protections to manage access to your files for all Git and Perforce users.

Git users work in one or more roles. A Git author is any user who changes a file. A Git puller downloads data into their own Git repo. A Git pusher copies changes from their own Git repo to another. Authors edit, pullers read, and pushers write. These three roles are often the same person. In Git Fusion, a Git committer is ignored since they are treated the same as the author.

To manage connections between Git Fusion and the Perforce server, the git-fusion-user account acts as a conduit. For the best user experience, each Git user must map to a corresponding user account on the Perforce server. This mapping is made through the email address, which must be identical for both the Git and Perforce user.

Sometimes it is impractical to create Perforce users for every author who has contributed to a Git repo. In these instances, the special Perforce user, unknown_git, can be created on the Perforce side to own changes by Git authors without Perforce accounts. With Git Fusion, a repo is a view into a specified set of files in the Perforce depot.

To control access to the repos, Git Fusion offers 3 levels of access. First is a repo-specific permission group to enable pull only, or pull and push abilities to a designated repo. Next is the global permission group which grants a user the ability to pull, or pull and push all repos. Lastly is the default permission counter which prohibits or enables all users from pulling or pushing. In order for any user to push to any repo, they must also have write permission in the standard P4 protect table.

When determining a user’s pull and push permissions, Git Fusion iterates through each permission layer, starting with the most specific, continuing until it finds and returns the first matching permission.

In this example, Daniel needs to pull from repo 1. Since the counter is set to the default value to enable any Git Fusion user to pull from any repo, he can get the file.

After some edits, he needs to push the file back to repo 1. Git Fusion now iterates through the permissions and sees Daniel is not in repo 1 group, but he is in the global repo push group so his push is successful.

Next, Jill has a file she pulled from repo 1 that’s been edited, and she wants to push it back. Currently she does not have any of the required permissions and the unknown_git user is not enabled, so the push fails. Once the admin adds her to repo 1 push group, her push is successful.

As a best practice, you should keep track of all your Git Fusion users, ensuring that users requiring only read access are in a pull group, and users requiring write access are in a push group.

This concludes the intro to Git Fusion permission setup. For detailed information on setting up permissions for your particular implementation, please review the Git Fusion User guide on

Thanks for watching.


Course - Git Workflows with GitSwarm and Git Fusion