Table Of Contents


A resource defines the desired state for a single configuration item present on a node that is under management by Chef. A resource collection—one (or more) individual resources—defines the desired state for the entire node. During a chef-client run, the current state of each resource is tested, after which the chef-client will take any steps that are necessary to repair the node and bring it back into the desired state.

Use the git resource to manage source control resources that exist in a git repository. git version 1.6.5 (or higher) is required to use all of the functionality in the git resource.


This resource is often used in conjunction with the deploy resource.


The syntax for using the git resource in a recipe is as follows:

git "name" do
  attribute "value" # see attributes section below
  action :action # see actions section below


  • git tells the chef-client to use the Chef::Provider::Git provider during the chef-client run.
  • "name" is the location in which the source files will be placed and/or synchronized with the files under source control management
  • attribute is zero (or more) of the attributes that are available for this resource
  • :action identifies which steps the chef-client will take to bring the node into the desired state

For example:

git "#{Chef::Config[:file_cache_path]}/app_name" do
  repository node[:app_name][:git_repository]
  revision node[:app_name][:git_revision]
  action :sync
  notifies :run, "bash[compile_app_name]"


  • the name of the resource is #{Chef::Config[:file_cache_path]}/libvpx
  • the repository and reference nodes tell the chef-client which repository and revision to use


This resource has the following actions:

Action Description
:sync Default. Use to update the source to the specified version, or to get a new clone or checkout.
:checkout Use to clone or check out the source. When a checkout is available, this provider does nothing.
:export Use to export the source, excluding or removing any version control artifacts.


This resource has the following attributes:

enable_checkout OLD: Use to check out a repo from master. NEW:

Attribute Description
additional_remotes An array of additional remotes that are added to the git repository configuration.
checkout_branch Use to do a one-time checkout from git or use when a branch in the upstream repository is named deploy. To prevent the git resource from attempting to check out master from master, set enable_checkout to false when using the checkout_branch attribute. See revision. Default value: deploy.
depth The number of past revisions that will be included in the git shallow clone. The default behavior will do a full clone.
destination The path to the location to which the source will be cloned, checked out, or exported. Default value: the name of the resource block. (See “Syntax” section above for more information.)
enable_checkout Use to check out a repo from master. Set to false when using the checkout_branch attribute to prevent the git resource from attempting to check out master from master. Default value: true.
enable_submodules Use to perform a sub-module initialization and update. Default value: false.

A Hash of environment variables in the form of {"ENV_VARIABLE" => "VALUE"}. (These variables must exist for a command to be run successfully.)


The git provider automatically sets the ENV['HOME'] and ENV['GIT_SSH'] environment variables. To override this behavior and provide different values, add ENV['HOME'] and/or ENV['GIT_SSH'] to the environment Hash.

group The system group that is responsible for the checked-out code.
provider Optional. Use to explicitly specify a provider.
reference The alias for revision.
remote The remote repository to be used when synchronizing an existing clone.
repository The URI for the git repository.

Use to specify a branch, tag, or commit to be synchronized with git. This can be symbolic, like HEAD or it can be a source control management-specific revision identifier. See checkout_branch. Default value: HEAD.

The value of the revision attribute may change over time. From one branch to another, to a tag, to a specific SHA for a commit, and then back to a branch. The revision attribute may even be changed in a way where history gets rewritten.

Instead of tracking a specific branch or doing a headless checkout, the chef-client maintains its own branch (via the git resource) that does not exist in the upstream repository. The chef-client is then free to forcibly check out this branch to any commit without destroying the local history of an existing branch.

For example, to explicitly track an upstream repository’s master branch:

revision 'master'

Use the git rev-parse and git ls-remote commands to verify that the chef-client is synchronizing commits correctly. (The chef-client always runs git ls-remote on the upstream repository to verify the commit is made to the correct repository.)

ssh_wrapper The path to the wrapper script used when running SSH with git. The GIT_SSH environment variable is set to this.
timeout The amount of time (in seconds) to wait for a command to execute before timing out. When this attribute is specified using the deploy resource, the value of the timeout attribute is passed from the deploy resource to the git resource.
user The system user that is responsible for the checked-out code. Default value: the home directory of this user, as indicated by the HOME environment variable.


The following examples demonstrate various approaches for using resources in recipes. If you want to see examples of how Chef uses resources in recipes, take a closer look at the cookbooks that Chef authors and maintains:

Use the git mirror

git "/opt/mysources/couch" do
  repository "git://"
  revision "master"
  action :sync

Use different branches

To use different branches, depending on the environment of the node:

if node.chef_environment == "QA"
   branch_name = "staging"
   branch_name = "master"

git "/home/user/deployment" do
   repository ""
   revision branch_name
   action :sync
   user "user"
   group "test"

where the branch_name variable is set to staging or master, depending on the environment of the node. Once this is determined, the branch_name variable is used to set the revision for the repository. If the git status command is used after running the example above, it will return the branch name as deploy, as this is the default value. Run the chef-client in debug mode to verify that the correct branches are being checked out:

$ sudo chef-client -l debug

Install an application from git using bash

The following example shows how Bash can be used to install a plug-in for rbenv named ruby-build, which is located in git version source control. First, the application is synchronized, and then Bash changes its working directory to the location in which ruby-build is located, and then runs a command.

 git "#{Chef::Config[:file_cache_path]}/ruby-build" do
   repository "git://"
   reference "master"
   action :sync

 bash "install_ruby_build" do
   cwd "#{Chef::Config[:file_cache_path]}/ruby-build"
   user "rbenv"
   group "rbenv"
   code <<-EOH
   environment 'PREFIX' => "/usr/local"

To read more about ruby-build, see here:

Upgrade packages from git

The following example shows the scm resource using the git short name as part of a larger recipe that is used to upgrade packages:

#  the following code sample comes from the ``source`` recipe in the ``libvpx-cookbook`` cookbook:

git "#{Chef::Config[:file_cache_path]}/libvpx" do
  repository node[:libvpx][:git_repository]
  revision node[:libvpx][:git_revision]
  action :sync
  notifies :run, "bash[compile_libvpx]", :immediately

Pass in environment variables

git "/opt/mysources/couch" do
  repository "git://"
  revision "master"
  environment  { 'VAR' => 'whatever' }
  action :sync