Clone vs. Fork

Fork a Repository

One of the key benefits of using Chef is the ability to use cookbooks from others in the Chef community. You can use cookbooks from an existing repository as-is, but if you want to make changes to any of its cookbooks, you will need to fork the repository, which creates an editable copy of the entire repository (including all of its branches and commits) in your own source control management (e.g. GitHub) account. Later, if you want to contribute back to the original project, you can make a pull request to the owner of the original cookbook repository so that your submitted changes can be merged into the main branch. By forking a repository, you're maintaining the relationship between the original version and your modified version, which makes it easier to push and pull code updates between the repositories. You are encouraged to fork RightScale's own repositories to make your own improvements to our cookbooks and later make pull request backs to RightScale so that we can incorporate your enhancements and make them available to others in the RightScale community so that everyone can benefit from each other's contributions. Typically, you will fork a repository if you want to make modifications to an existing repository where you only have 'read-only' access.

See Fork a Cookbook Repository.

Note: In order to submit code submissions, you must complete a RightScale Contributors Agreement found here.

Clone a Repository

You should clone a repository if you plan to push your changes back to the same repository where you have read+write access privileges. You should also clone a repository if you are building a new repository that is unique. This way, you can start with the basic structure of a cookbook instead of creating it from scratch.

See Clone a Cookbook Repository.